From mcooper%acamar.usc.edu@usc.edu Tue Aug 4 16:03:51 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA13538; Tue, 4 Aug 92 16:03:51 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA16385; Tue, 4 Aug 92 16:03:51 PDT Sender: "Michael A. Cooper" Date: Tue, 4 Aug 92 16:03:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Rdist Version 6.0beta Message-Id: Welcome to the rdist mailling list. This is a new mailling list intended for people working on or interested in rdist. It is primarily intended for topics related to rdist version 6.0 which is available via anonymous ftp from usc.edu as /pub/rdist/rdist.tar.Z. You are on this list because at some point you either sent in bug fixes or suggestions to the Berkeley CSRG folks or you contacted me regarding rdist version 5.0beta (which never left beta testing due to all the work done on version 6). If you do not wish to be on this list, please send email to "rdist-request@usc.edu" and you will be swiftly removed. You can send mail to this list using the address "rdist@usc.edu". Archives of the list are out for ftp on usc.edu in /pub/rdist/mail.archive. This is the first beta release of rdist 6.0. The README and ChangeLog files are appended below. Rdist version 6.0 is included in 4.4BSD. It will be also be posted to comp.sources.unix after the beta test is over, which I hope will occur by the end of August or September at the latest. Michael A. Cooper, University Computing Services, U of Southern California INTERNET: mcooper@usc.edu PHONE: (213) 740-2957 UUCP: ...!uunet!usc!mcooper BITNET: mcooper@ramoth Rdist Version 6.0 8/4/92 Michael Cooper University of Southern California University Computing Services mcooper@usc.edu GENERAL INFORMATION This is version 6.0 of Rdist from USC. It is based on rdist from 4.3BSD (classic). It includes all fixes for all bugs known to the CSRG Berkeley folks. It has been running at USC for some time now on a wide variety of platforms. This version of rdist is not directly compatible with rdist distributed with 4.3BSD and subsequent vendor releases, but does indirectly provide full backward compatibility. See COMPATIBILITY below for details. The current version of rdist is available via anonymous ftp on usc.edu under /pub/rdist. The current version is always retrievable as file "/pub/rdist/rdist.tar.Z". CHANGES/FEATURES See the ChangeLog file. The end of the file contains the major new features compared to "old" rdist. PLATFORMS This version of rdist has been tested on the following: Alliant 2800 Concentrix 2.2 Alliant FX/80 Concentrix 5.X DEC MIPS Ultrix 4.2 HP 9000/300 Mt Xinu MORE/bsd (4.3BSD) HP 9000/300 HP/UX 7.0.5 with GCC 2.2.2 HP 9000/400 HP/UX 7.0.5 with GCC 2.2.2 IBM RS6000 AIX 3.1, 3.2 NeXT Mach 2.1 Sun-3 SunOS 4.0.3, 4.1.1 Sun-386i SunOS 4.0.1 Sun-4 SunOS 4.0.3, 4.1.1, 4.1.2 It should work on just about any BSD based Unix with little or no modification. COMPATIBILITY This version of rdist differs greatly from older versions (as distributed with 4.3BSD) in that the client and the server portions are seperated into two distinct programs, rdist and rdistd, respectively. The protocol used to communicate between the client and server has also been extensively modified. These two items make providing "builtin" compatibility very difficult. However, backwards compatibility is possible, provided you have a binary or source copy of the old rdist. The way the old rdist started a server rdist is to run "rdist -Server". If the new rdist is run with the "-Server" option, then it will exec a copy of the old rdist (usually /usr/old/rdist or /usr/ucb/oldrdist). In this way, you get compatibility with hosts running the old rdist attempting to rdist to a machine running new rdist. If your host running new rdist wants to rdist to a host running the old rdist, then it must run the old rdist program (/usr/old/rdist or /usr/ucb/oldrdist). The definetion _PATH_OLDRDIST in pathnames.h controls the location of the old rdist. If this is not defined, or the defined program does not exist at runtime, then rdist will print an error when run with the "-Server" option. INSTALLATION 1) Edit "Makefile" and follow the comments on what parameters may need to be set and/or changed. 2) Edit "config.h" and follow the comments on what parameters may need to be set and/or changed. 3) Run "make" to compile everything. 4) Run "make install" to install the binaries and "make install.man" to install the manual pages. KNOWN PROBLEMS * The "special" command is currently broken under HP/UX. MAIL LIST The maillist "rdist@usc.edu" is an unmoderated list for people who work on rdist. It's purpose is for the exchange of ideas, comments, and bug fixes for rdist. To subscribe or unsubscribe, send email to "rdist-request@usc.edu". Archives are available for anonymous ftp from usc.edu as /pub/rdist/mail.archive. BUG REPORTS Bug reports should be sent to "rdist@usc.edu". This is a mailling list for people who work on rdist. To join this list, send email to "rdist-request@usc.edu". Bug reports should include: 1) The version of the rdist client and server you are running (use the -V option to rdist and rdistd) 2) The platform (machine + OS name + OS version) 3) A full description of the problem 4) If you have a patch to fix the problem, a context diff (diff -c) of the original files vs. the fixed files NOTES Older Unix systems may have a bug in their rcmd() library function. The bug allowed a user process to run out of file descriptors if too many connection attempts failed. The problem is that the socket would never be closed if the connect() failed. This could eventually lead to running out of file descriptors if enough connections failed. Most current Unix's like SunOS 4.0.3 and later have this fixed. Here is a diff to (I think) the SunOS 3.5 rcmd() to fix the problem: *************** *** 51,56 **** --- 65,71 ---- timo *= 2; goto retry; } + (void) close(s); perror(hp->h_name); return (-1); } RCS INFO This is rcs info for this file: $Id: README,v 6.1 1992/08/04 22:16:34 mcooper Exp mcooper $ Changes up to Release 6.0beta.2: Tue Aug 4 15:20:46 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Rename patchlevel.h to version.h and move VERSION define from config.h to version.h. Tue Aug 4 15:03:53 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Cleanup comments about configuration and such in Makefile, config.h, pathnames.h, and README. Fri Jul 31 14:59:45 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix to fix "Don't know how to make ..." fix. Thu Jul 30 14:34:46 1992 Michael A. Cooper (mcooper at acamar.usc.edu) * Add -V options to rdist and rdistd to print version information. * Portability changes and support for HP/UX from Allan Weber (weber@sipi.usc.edu). Changes up to 6.0alpha3: Fri Jul 24 11:27:08 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix bug with ^C of "rdist" resulting in a core dump. An invalid jmpbuf was being used in a call to longjmp(). * Fix problem with modify time not being set on NeXT 2.1 machines. Also now set the access time of newly installed/updated file to be the current time instead of the atime from the source machine. Mon Jul 20 12:46:20 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix misspelling of ${MISSINGOBJS} in Makefile. * Fix problem with "Don't know how to rdist to ..." error being printed when it shouldn't be. Thu Jul 16 10:58:09 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem with hosts marked as + in the distfile having multiple child update the host simaltaneously, which causes race conditions when updating certain targets. Changes up to 6.0alpha2: Tue Jul 14 12:40:24 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Cleanup and fix rdistfilter. Thu Jul 9 16:15:00 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Back out reverse polling code to be clean and remove one source of possible bugs. Tue Jul 7 12:37:40 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Port back to AIX/RS6000 (3.2), Alliant Concentrix 5.5, Sun-386i (SunOS 4.0.1), DEC MIPS (Ultrix 4.2), NeXT (Mach 2.1). Mainly this was changes to config.h and creation of isexec.c to make porting to new platforms more straigtforward. Changes up through 6.0alpha - The client and the server are now split into two seperate programs (rdist and rdistd). The client (rdist) looks like older versions of rdist. Instead of running "/usr/ucb/rdist" on a remote machine, it now runs "rdistd". Notice that it doesn't run "/usr/ucb/rdistd" or use any explicit pathname. This is to improve portability to various different platforms where "/usr/ucb" may not exist. What this means is that the server must be somewhere in the user's default $PATH if the client is to successfully run rdistd. This also means that the server no longer needs to be setuid root. Only the client still needs setuid root (because it uses priv'ed ports). This should cut down a bit on potential security holes. Because the server (rdistd) resides in normal user "bin" directories, it requires the -S option in order to run. This is to avoid users accidentially typing "rdistd" instead of "rdist". - If the client (rdist) is started with the "-Server" option (which is the old rdist method of starting rdist in server mode), it will attempt to run the old version of rdist, if it was compiled with the name of that program. This is for backwards compatibility and should allow this version of rdist to co-exist with older versions. - Add support for running a pre-processor (m4 by default) over the distfile before processing. - If a connection to a host fails, avoid trying to recontact host again. - Use getopt() for command line option parsing. I hate getopt(), but everybody wants to use it. Sigh. - A slew of new options. See the man page for details. - Add buffered remote read code from Chris Torek along with some other code cleanups. - Check free space and files on a filesystem before installing. This code will (optionally) check the amount of free space and files (inodes) on a filesystem before installing. If the free space and/or files is less then specified by the initiator, then the target will not be installed and an error returned. This is useful for preventing rdist from filling up a remote filesystem. - Concurrent rdist processes. Update multiple hosts concurrently by fork'ing children with each child updating one host. The number of children is limited to a given number (usually 4), but is controllable with a command line option (-M). - Add "setargs" code to set process arguments to indicate what host we are talking to. A protocol change was required for this. - If a remote target resides on a NFS or read-only filesystem, then don't try to update target on that host. This elimates having to have millions of seperate lists and exceptions for hosts with certain parts NFS mounted or read-only mounted and hosts with everything mounted read-write. - Set timeout alarms to avoid hanging when something happens to a server during a session. Remove servers can sometimes get into a state either during startup or during a session where they will never send a response back to the local rdist master process. - Add ability to rdist a symlink to a directory and vice-versa. Previously, this would fail. - Add checking and setting of file modes. If a file's mode is not what it should be, the entire file is updated in case there was any tampering. If the target is a directory, then just the mode of the directory is updated. - Major code cleanup and restructuring. Major portions of the code has been re-written and/or restructured. - Add config.h file for configuration related items. - Fixed a security hole with setreuid(). - Add better error messages. We now distinguish between LOCAL and REMOTE errors. RCS INFO $Id: ChangeLog,v 1.1 1992/08/04 22:28:49 mcooper Exp mcooper $ From neal@neal.ctd.comsat.com Wed Aug 5 06:57:38 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA12077; Wed, 5 Aug 92 06:57:38 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Aug 92 09:57 EDT Message-Id: Date: Wed, 5 Aug 92 09:57 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Tue, 4 Aug 92 16:03:48 PDT Subject: Rdist Version 6.0beta Thanks. Here is my *preliminary* port to hp90008xx/hp90007xx. Highlights: 1. Starting somewhere around version 8.07, hpux is no longer predefined. Instead __hpux is. 2. Added isexec test for risk machines. 3. Binary can't go in /usr/ucb. HPUX doesn't have this. I put it in /local/etc/. ---------------------------------------------------------- diff -r -c rdist-6.0beta.2/Makefile rdist-6.0beta.2-hpux/Makefile *** rdist-6.0beta.2/Makefile Tue Aug 4 18:26:20 1992 --- rdist-6.0beta.2-hpux/Makefile Wed Aug 5 09:37:23 1992 *************** *** 43,49 **** # CLIENT - Name of client program (rdist) in ${BIN} # SERVER - Name of server program (rdistd) in ${BIN} # ! BIN = /usr/ucb MAN = /usr/man CLIENT = rdist SERVER = rdistd --- 43,49 ---- # CLIENT - Name of client program (rdist) in ${BIN} # SERVER - Name of server program (rdistd) in ${BIN} # ! BIN = /local/etc MAN = /usr/man CLIENT = rdist SERVER = rdistd *************** *** 59,65 **** # the Berkeley Regular Expression routines re_comp() and re_exec(). # #MISSINGOBJS = strerror.o strdup.o regex.o ! MISSINGOBJS = # # LIBS - Libraries to load at load time (normally blank) --- 59,65 ---- # the Berkeley Regular Expression routines re_comp() and re_exec(). # #MISSINGOBJS = strerror.o strdup.o regex.o ! MISSINGOBJS = regex.o # # LIBS - Libraries to load at load time (normally blank) diff -r -c rdist-6.0beta.2/config.h rdist-6.0beta.2-hpux/config.h *** rdist-6.0beta.2/config.h Tue Aug 4 18:21:28 1992 --- rdist-6.0beta.2-hpux/config.h Wed Aug 5 09:35:56 1992 *************** *** 49,54 **** --- 49,60 ---- */ #include "paths.h" + #ifdef __hpux + #ifndef hpux + #define hpux + #endif + #endif + /* * Define _PATH_OLDRDIST to be the name of the old rdist. If you * want to be backwards compability with the old rdist, uncomment *************** *** 175,180 **** --- 181,190 ---- #else #if defined(NeXT) #define HAVE_MACHO + #else + #if defined(__hp9000s800) + #define HAVE_HPEXEC + #endif /* HAVE_HPEXEC */ #endif /* HAVE_MACHO */ #endif /* HAVE_COFF */ #endif /* HAVE_AOUT */ diff -r -c rdist-6.0beta.2/isexec.c rdist-6.0beta.2-hpux/isexec.c *** rdist-6.0beta.2/isexec.c Tue Jul 7 15:35:59 1992 --- rdist-6.0beta.2-hpux/isexec.c Wed Aug 5 09:36:16 1992 *************** *** 91,96 **** --- 91,112 ---- } #endif /* HAVE_COFF */ + #ifdef HAVE_HPEXEC + #define ISEXEC(a) ((a) == EXEC_MAGIC || (a) == SHARE_MAGIC || (a) == DEMAND_MAGIC) + #include + static int _isexec(fd) + int fd; + { + struct header ehdr; + + if ((read(fd, &ehdr, sizeof(ehdr)) == sizeof(ehdr)) && + ISEXEC(ehdr.a_magic)) + return(TRUE); + else + return(FALSE); + } + #endif /* __hp9000s800 */ + #ifdef HAVE_MACHO /* * Mach-O format /local/users/neal% From neal@neal.ctd.comsat.com Wed Aug 5 07:32:29 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA12852; Wed, 5 Aug 92 07:32:29 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Aug 92 10:32 EDT Message-Id: Date: Wed, 5 Aug 92 10:32 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Tue, 4 Aug 92 16:03:48 PDT Subject: Rdist Version 6.0beta bug report Here's the first problem I found. I tried to update /local/etc/amd on a remote. But this had been done already, and the remote was already executing /local/etc/amd.OLD. Here is an excerpt: --------------------------------- recieved ACK sendit(amd, 0) except(/local/etc/amd) update(amd, 0, 4000418c) >>> Cmd = Q (\121) Msg = "amd" <<< Cmd = Y (\131) Msg = "196608 707585077 711" local mode of amd is 711, remote mode 711. update status amd (/local/etc/amd) is 2 picard: updating: /local/etc/amd >>> Cmd = R (\122) Msg = "0 711 200704 711814134 713024822 root sys amd" response() <<< Cmd =  (\005) Msg = "" recieved ACK Send file 'amd' 200704 bytes Send file 'amd' complete. >>> Cmd =  (\005) Msg = "" response() <<< Cmd =  (\003) Msg = "remove failed: /local/etc/amd.OLD: Text file busy" picard: remove failed: /local/etc/amd.OLD: Text file busy response() --------------------------------- This is OK, the problem is that the protocol HANGS INDEFINATELY at this point! I'm not sure what's the correct cure. Thanks From neal@neal.ctd.comsat.com Wed Aug 5 08:03:52 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA13780; Wed, 5 Aug 92 08:03:52 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Aug 92 11:03 EDT Message-Id: Date: Wed, 5 Aug 92 11:03 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Tue, 4 Aug 92 16:03:48 PDT Subject: Rdist Version 6.0beta Fix for bug reported in server.c This code was incorrect. If rename failed due to TXTBSY, don't try to remove it!! -------------------------------------------- diff -r -c rdist-6.0beta.2/server.c rdist-6.0beta.2-hpux/server.c *** rdist-6.0beta.2/server.c Thu Jul 30 17:11:45 1992 --- rdist-6.0beta.2-hpux/server.c Wed Aug 5 10:57:55 1992 *************** *** 716,726 **** "rename failed: %s -> %s: %s", savefile, target, SYSERR); } - if (!(opts & SAVETARGETS) && - unlink(savefile) < 0) - note("remove failed: %s: %s", - savefile, SYSERR); } } else error("rename failed: %s -> %s: %s", --- 716,724 ---- "rename failed: %s -> %s: %s", savefile, target, SYSERR); + else + note("renamed old file to %s", savefile ); } } } else error("rename failed: %s -> %s: %s", From neal@neal.ctd.comsat.com Wed Aug 5 08:35:01 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA14519; Wed, 5 Aug 92 08:35:01 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Aug 92 11:35 EDT Message-Id: Date: Wed, 5 Aug 92 11:35 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Tue, 4 Aug 92 16:03:48 PDT Subject: Rdist Version 6.0beta Patch for server.c for ETXTBSY, take #2. Sorry about previous patch. This is probably more like it: ----------------------------------------------------------- *** rdist-6.0beta.2/server.c Thu Jul 30 17:11:45 1992 --- rdist-6.0beta.2-hpux/server.c Wed Aug 5 11:29:28 1992 *************** *** 717,732 **** savefile, target, SYSERR); } ! if (!(opts & SAVETARGETS) && ! unlink(savefile) < 0) ! note("remove failed: %s: %s", ! savefile, SYSERR); } ! } else ! error("rename failed: %s -> %s: %s", new, target, SYSERR); ! (void) unlink(new); ! return; } if (opts & COMPARE) --- 717,731 ---- savefile, target, SYSERR); } ! else ! note( "renamed %s to %s", target, savefile ); } ! } ! else { ! error("rename failed: %s -> %s: %s", new, target, SYSERR); ! (void) unlink(new); ! } } if (opts & COMPARE) /local/users/neal% From neal@neal.ctd.comsat.com Wed Aug 5 10:25:39 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA18572; Wed, 5 Aug 92 10:25:39 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Aug 92 13:25 EDT Message-Id: Date: Wed, 5 Aug 92 13:25 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Tue, 4 Aug 92 16:03:48 PDT Subject: Rdist Version 6.0beta/HPUX diffs 'special' seems to work on HPUX if you #undef SETARGS. I don't think this will catch anyone at HP by surprise. If I recall correctly, on HPUX, "that trick never works". So, here is a complete patch for HPUX: ------------------------------------------------------------------------ diff -r -c rdist-6.0beta.2/Makefile rdist-6.0beta.2-hpux/Makefile *** rdist-6.0beta.2/Makefile Tue Aug 4 18:26:20 1992 --- rdist-6.0beta.2-hpux/Makefile Wed Aug 5 10:07:07 1992 *************** *** 43,49 **** # CLIENT - Name of client program (rdist) in ${BIN} # SERVER - Name of server program (rdistd) in ${BIN} # ! BIN = /usr/ucb MAN = /usr/man CLIENT = rdist SERVER = rdistd --- 43,49 ---- # CLIENT - Name of client program (rdist) in ${BIN} # SERVER - Name of server program (rdistd) in ${BIN} # ! BIN = /local/etc MAN = /usr/man CLIENT = rdist SERVER = rdistd *************** *** 51,57 **** # # Name of your install program # ! INSTALL = install # # You may need to add things like "strerror.o" here if your OS doesn't --- 51,57 ---- # # Name of your install program # ! INSTALL = /usr/local/bin/ginstall # # You may need to add things like "strerror.o" here if your OS doesn't *************** *** 59,65 **** # the Berkeley Regular Expression routines re_comp() and re_exec(). # #MISSINGOBJS = strerror.o strdup.o regex.o ! MISSINGOBJS = # # LIBS - Libraries to load at load time (normally blank) --- 59,65 ---- # the Berkeley Regular Expression routines re_comp() and re_exec(). # #MISSINGOBJS = strerror.o strdup.o regex.o ! MISSINGOBJS = regex.o # # LIBS - Libraries to load at load time (normally blank) diff -r -c rdist-6.0beta.2/config.h rdist-6.0beta.2-hpux/config.h *** rdist-6.0beta.2/config.h Tue Aug 4 18:21:28 1992 --- rdist-6.0beta.2-hpux/config.h Wed Aug 5 13:14:04 1992 *************** *** 49,54 **** --- 49,60 ---- */ #include "paths.h" + #ifdef __hpux + #ifndef hpux + #define hpux + #endif + #endif + /* * Define _PATH_OLDRDIST to be the name of the old rdist. If you * want to be backwards compability with the old rdist, uncomment *************** *** 88,95 **** --- 94,103 ---- * Set process args to messages that show up when running ps(1) */ #ifndef _CENTERLINE_ + #ifndef __hpux #define SETARGS #endif + #endif /* * Default value for the maximum number of clients to update at once. *************** *** 175,180 **** --- 183,192 ---- #else #if defined(NeXT) #define HAVE_MACHO + #else + #if defined(__hp9000s800) + #define HAVE_HPEXEC + #endif /* HAVE_HPEXEC */ #endif /* HAVE_MACHO */ #endif /* HAVE_COFF */ #endif /* HAVE_AOUT */ Only in rdist-6.0beta.2-hpux: distfile diff -r -c rdist-6.0beta.2/isexec.c rdist-6.0beta.2-hpux/isexec.c *** rdist-6.0beta.2/isexec.c Tue Jul 7 15:35:59 1992 --- rdist-6.0beta.2-hpux/isexec.c Wed Aug 5 09:36:16 1992 *************** *** 91,96 **** --- 91,112 ---- } #endif /* HAVE_COFF */ + #ifdef HAVE_HPEXEC + #define ISEXEC(a) ((a) == EXEC_MAGIC || (a) == SHARE_MAGIC || (a) == DEMAND_MAGIC) + #include + static int _isexec(fd) + int fd; + { + struct header ehdr; + + if ((read(fd, &ehdr, sizeof(ehdr)) == sizeof(ehdr)) && + ISEXEC(ehdr.a_magic)) + return(TRUE); + else + return(FALSE); + } + #endif /* __hp9000s800 */ + #ifdef HAVE_MACHO /* * Mach-O format diff -r -c rdist-6.0beta.2/server.c rdist-6.0beta.2-hpux/server.c *** rdist-6.0beta.2/server.c Thu Jul 30 17:11:45 1992 --- rdist-6.0beta.2-hpux/server.c Wed Aug 5 13:16:39 1992 *************** *** 717,732 **** savefile, target, SYSERR); } ! if (!(opts & SAVETARGETS) && ! unlink(savefile) < 0) ! note("remove failed: %s: %s", ! savefile, SYSERR); } ! } else ! error("rename failed: %s -> %s: %s", new, target, SYSERR); ! (void) unlink(new); ! return; } if (opts & COMPARE) --- 717,731 ---- savefile, target, SYSERR); } ! else ! note( "renamed %s to %s", target, savefile ); } ! } ! else { ! error("rename failed: %s -> %s: %s", new, target, SYSERR); ! (void) unlink(new); ! } } if (opts & COMPARE) From mcooper%acamar.usc.edu@usc.edu Wed Aug 5 18:08:20 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA09829; Wed, 5 Aug 92 18:08:20 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA19192; Wed, 5 Aug 92 18:08:21 PDT Sender: "Michael A. Cooper" Date: Wed, 5 Aug 92 18:08:18 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Rdist 6.0beta.3 Message-Id: Patchlevel 3 of rdist 6.0beta is now out for ftp. Appended below is the excerp of changes from ChangeLog. Thanks to everyone who contributed comments and patches! Rich Salz mentions that "some hpux" machines have support for the following "setargs" type interface: #include (void)pstat(PSTAT_SETCMD, buff, 0, 0, 0); Would the HP/UX people please check to see if there HP/UX machines support this? If so, I'll add it in as an alternate to the setproctitle stuff. mike Changes up to Release 6.0beta.3: Wed Aug 5 14:10:22 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem with ETXTBSY code not working. (Neal Becker) * Add support for HP 9000/[78]00 executable format. (Neal Becker) * Defining SETARGS breaks "special" command under HP/UX. (Neal Becker) * Change #ifdef's of "hpux" to be "__hpux" for compability with both HP/UX 7.* and 8.* OS versions. (Neal Becker & Allan Weber) * Get rid of #define's in defs.h by compiling yacc with -d. Also change tokens like SM (';') to be real chars in the grammer instead of tokens for clarity. (Rich) * Change ISDIR -> S_ISDIR, ISREG -> S_ISREG, ISLNK -> S_ISLNK to be POSIX compliant. (Rich) * Document in rdist.1 how rdist runs rdistd. * Replace ".in +5" with ".RS/.RE" in rdist.1. (Rich) * Remove preprocessor support. Use "m4 distfile | rdist -f -" for same effect without the ugly code. (Rich) * Clarify -N and -O options in rdist.1 (Rich). * Document that we can't use strchr() in place of any() because most systems strchr() can't handle some of the input we pass. From neal@neal.ctd.comsat.com Thu Aug 6 05:47:09 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA01182; Thu, 6 Aug 92 05:47:09 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Thu, 6 Aug 92 08:47 EDT Message-Id: Date: Thu, 6 Aug 92 08:47 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Wed, 5 Aug 92 18:08:18 PDT Subject: Rdist 6.0beta.3 Only one litte problem: ----------------------------------- *** isexec.c~ Wed Aug 5 19:13:59 1992 --- isexec.c Thu Aug 6 08:32:36 1992 *************** *** 117,124 **** * HP 9000/[78]00 executable formate */ ! #define ISEXEC(a) ((a) == EXEC_MAGIC || (a) == SHARE_MAGIC || ! (a) == DEMAND_MAGIC) #include static int _isexec(fd) --- 117,123 ---- * HP 9000/[78]00 executable formate */ ! #define ISEXEC(a) ((a) == EXEC_MAGIC || (a) == SHARE_MAGIC || (a) == DEMAND_MAGIC) #include static int _isexec(fd) ------------------------------------------------------------- Since this pstat stuff is not universal and is not documented (at least not in my set of manpages) and since it seems quite unnecessary, and since HP is going to a new major release quite soon, I'd just as soon forget about setproctitle on hp. BTW: I still have a problem with log files getting hosed by mutilple processes trying to update the same log file. At least I think that's whats happening. I often wind up with strings of null characters (^@) in them. I don't have an answer for this. (Had the same problem with rdist5). ToDo: Nicer log files. Use syslog? I use cron to run rdist and just create logs with >>, but this doesn't give much info (like date). Besides, the logs thus generated are full of useless info. From mcooper%acamar.usc.edu@usc.edu Thu Aug 6 10:09:14 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA09962; Thu, 6 Aug 92 10:09:14 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA19689; Thu, 6 Aug 92 10:09:15 PDT Sender: "Michael A. Cooper" Date: Thu, 6 Aug 92 10:09:12 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Subject: Re: Rdist 6.0beta.3 In-Reply-To: Your message of Thu, 6 Aug 92 08:47 EDT Cc: rdist@usc.edu Message-Id: > Only one litte problem: Fixed. > > Since this pstat stuff is not universal and is not documented (at > least not in my set of manpages) and since it seems quite unnecessary, > and since HP is going to a new major release quite soon, I'd just as > soon forget about setproctitle on hp. > Sounds reasonable. > BTW: I still have a problem with log files getting hosed by mutilple > processes trying to update the same log file. At least I think that's > whats happening. I often wind up with strings of null characters (^@) > in them. I don't have an answer for this. (Had the same problem with > rdist5). > > ToDo: Nicer log files. Use syslog? I use cron to run rdist and just > create logs with >>, but this doesn't give much info (like date). > Besides, the logs thus generated are full of useless info. > Yeah, I'm afraid that this is an artifact of having multiple clients update at once. Setting "line buffering" via setlinebuf() helps a lot, but doesn't quite do the job. I don't want to log message to syslog() because this isn't user friendly. Normal users _do_ use rdist privately. Expecting them to look in a syslog file somewhere isn't reasonable. This problem can be solved by using select() in the parent rdist to read from each child and output things in an orderly manner. The problem with this is select() isn't available on older systems. Ideas? Comments? BTW, the perl script "rdistfilter.pl" (which is in the distribution) is what I use to filter the output from rdist into something readable. It works fairly well. There are occasionaly pieces of "orphaned" characters due to two children outputing to stdout at the same time. mike From neal@neal.ctd.comsat.com Thu Aug 6 10:41:20 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA11442; Thu, 6 Aug 92 10:41:20 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Thu, 6 Aug 92 13:41 EDT Message-Id: Date: Thu, 6 Aug 92 13:41 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Thu, 6 Aug 92 10:09:12 PDT Subject: Rdist 6.0beta.3 >>>>> On Thu, 6 Aug 92 10:09:12 PDT, Michael A. Cooper said: > BTW: I still have a problem with log files getting hosed by mutilple > processes trying to update the same log file. At least I think that's > whats happening. I often wind up with strings of null characters (^@) > in them. I don't have an answer for this. (Had the same problem with > rdist5). > > ToDo: Nicer log files. Use syslog? I use cron to run rdist and just > create logs with >>, but this doesn't give much info (like date). > Besides, the logs thus generated are full of useless info. > Michael> Yeah, I'm afraid that this is an artifact of having multiple clients Michael> update at once. Setting "line buffering" via setlinebuf() helps a Michael> lot, but doesn't quite do the job. I don't want to log message to Michael> syslog() because this isn't user friendly. Normal users _do_ use Michael> rdist privately. Expecting them to look in a syslog file somewhere Michael> isn't reasonable. Add a command line option to log anything interesting? Interesting things are usually: * anything going wrong * any files updated Uninteresting things include: * rdist ran fine and nothing got updated Currently, we are told about every time rdist is run and *nothing* happened. I use rdist to about 40 nodes once per hour. Michael> This problem can be solved by using select() in the parent rdist to Michael> read from each child and output things in an orderly manner. The Michael> problem with this is select() isn't available on older systems. Michael> Ideas? Comments? I don't really have much experience here. (Is a system without select() worth having?) Neal. From tchrist@pixel.convex.com Thu Aug 6 10:46:36 1992 Return-Path: Received: from convex.convex.com by usc.edu (5.64+/SMI-3.0DEV3) id AA11792; Thu, 6 Aug 92 10:46:36 PDT Received: from pixel.convex.com by convex.convex.com (5.64/1.35) id AA12587; Thu, 6 Aug 92 12:46:01 -0500 Received: from localhost by pixel.convex.com (5.64/1.28) id AA06583; Thu, 6 Aug 92 12:45:53 -0500 To: neal@ctd.comsat.com (Neal Becker) Cc: mcooper@usc.edu, rdist@usc.edu Subject: Re: Rdist 6.0beta.3 In-Reply-To: Neal Becker's message of Thu, 06 Aug 92 13:41:00 EDT. References: Reply-To: tchrist@convex.com Date: Thu, 06 Aug 92 12:45:52 CDT Message-Id: <6579.713123152@pixel.convex.com> From: Tom Christiansen > Add a command line option to log anything interesting? Interesting > things are usually: > * anything going wrong > * any files updated No no no. This should be done via a filter. I have to look at the way the new version is handling mail notification as well. One rdist run should never trigger more than one piece of mail to the same person. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist Verbosity leads to unclear, inarticulate things. -- Dan Quayle From rsalz@osf.org Tue Aug 11 05:42:07 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3) id AA15695; Tue, 11 Aug 92 05:42:07 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA28136; Tue, 11 Aug 92 08:40:11 -0400 Received: by earth.osf.org (5.64/4.7) id AA02210; Tue, 11 Aug 92 08:40:10 -0400 Date: Tue, 11 Aug 92 08:40:10 -0400 From: rsalz@osf.org Message-Id: <9208111240.AA02210@earth.osf.org> To: rdist@usc.edu Subject: Logging >> ToDo: Nicer log files. Use syslog? I use cron to run rdist and just >> create logs with >>, but this doesn't give much info (like date). >> Besides, the logs thus generated are full of useless info. This is definitely a tricky point. What model should rdist follow? - Unix philosophy: only complain (to stderr) if problems; add a -v (or -v#) for verbose output. - make: print each command done. - make -s: print only summaries, such as "Updated foo on bar.edu" I'm not sure what is best. Perhaps different "-v" flags could get different verbosity, or a "-q" for quiet (summary only?) output. This is where being on the beta comes in to play -- someone who uses it a lot should categorize the messages and see what model falls out. Without question, the rdist server (which runs on the client host -- gee, just like X :-) should log through syslog. The rdist program should send output to stdout. The output should be cleaned up so that it's not mingled/mangled when doing simultaneous updates. - setlinebuff is not portable (if you won't use select you definitely can't use this). I also think that counting on it to do the right thing is, at best, unwarranted chumminess. I think sprintf+write is about the best you can do. - Perhaps each child sends its output up a pipe to which reads each one and writes the output? (A first flag byte indicates whether the next 'n' bytes are for stdout or stderr.) - If each client started each line of output with the name of the host it was working on, then filtering output (if it's not mangled) is trivial -- rdistfilter.pl becomes fluff. /r$ From neal@neal.ctd.comsat.com Tue Aug 11 06:09:17 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA16819; Tue, 11 Aug 92 06:09:17 PDT Received: by neal.ctd.comsat.com (/\==/\ Smail3.1.25.1 #25.17) id ; Tue, 11 Aug 92 09:08 EDT Message-Id: Date: Tue, 11 Aug 92 09:08 EDT From: neal@ctd.comsat.com (Neal Becker) To: rsalz@osf.org Cc: rdist@usc.edu In-Reply-To: rsalz@osf.org's message of Tue, 11 Aug 92 08:40:10 -0400 <9208111240.AA02210@earth.osf.org> Subject: Logging ToDo: Nicer log files. Use syslog? I use cron to run rdist and just create logs with >>, but this doesn't give much info (like date). Besides, the logs thus generated are full of useless info. > This is definitely a tricky point. What model should rdist follow? > - Unix philosophy: only complain (to stderr) if problems; > add a -v (or -v#) for verbose output. Well, I guess the things I'm interested in seeing are abnormal events. Usually this is: 1) Any errors or problems encountered 2) Files that were successfully updated (this is verbose level 1) I do *not* want to know about (by default) every time rdist was run on every host. This is -v99. From mcooper%acamar.usc.edu@usc.edu Tue Aug 11 11:02:54 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA27928; Tue, 11 Aug 92 11:02:54 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA29968; Tue, 11 Aug 92 10:19:28 PDT Sender: "Michael A. Cooper" Date: Tue, 11 Aug 92 10:19:25 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rsalz@osf.org Cc: rdist@usc.edu Subject: Re: Logging In-Reply-To: Your message of Tue, 11 Aug 92 08:40:10 -0400 Message-Id: > >> ToDo: Nicer log files. Use syslog? I use cron to run rdist and just > >> create logs with >>, but this doesn't give much info (like date). > >> Besides, the logs thus generated are full of useless info. > This is definitely a tricky point. What model should rdist follow? > - Unix philosophy: only complain (to stderr) if problems; > add a -v (or -v#) for verbose output. > - make: print each command done. > - make -s: print only summaries, such as "Updated foo on bar.edu" > I'm not sure what is best. Perhaps different "-v" flags could get > different verbosity, or a "-q" for quiet (summary only?) output. This is > where being on the beta comes in to play -- someone who uses it a lot > should categorize the messages and see what model falls out. > > Without question, the rdist server (which runs on the client host -- gee, > just like X :-) should log through syslog. > The server (on the remote target host) already logs errors and such to syslog. It's unclear whether you want the server to also log locally (through syslog) the "normal" messages that get sent back and are printed by the "parent" rdist. The "notify" option takes care of notifing people local to the remote/target host what happened, if they're interested. > The rdist program should send output to stdout. The output should be > cleaned up so that it's not mingled/mangled when doing simultaneous > updates. > - setlinebuff is not portable (if you won't use select you > definitely can't use this). I also think that counting on > it to do the right thing is, at best, unwarranted chumminess. > I think sprintf+write is about the best you can do. > - Perhaps each child sends its output up a pipe to which reads > each one and writes the output? (A first flag byte indicates > whether the next 'n' bytes are for stdout or stderr.) > - If each client started each line of output with the name of > the host it was working on, then filtering output (if it's > not mangled) is trivial -- rdistfilter.pl becomes fluff. Each child rdist already prints the host it's working on as the first argument on each line. rdistfilter takes advantage of this. There's two issues here. The first is deciding what the output should look like and the second is deciding how to accomplish it. I'd really like to hear from everyone on both of these. Let's take a little survey on the issue of select(). What major _current_ versions of Unix do not have select() these days? The 4.2BSD based Unix's like SunOS obviously have it. In particuliar, how about HPUX? mike From neal@ctd.comsat.com Fri Aug 28 09:19:09 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA18564; Fri, 28 Aug 92 09:19:09 PDT Received: by neal.ctd.comsat.com (Smail3.1.26.7 #6) id m0mO92N-0003TdC; Fri, 28 Aug 92 12:19 EDT Message-Id: Date: Fri, 28 Aug 92 12:19 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: wish list One thing that would be nice is to be able to add to and subtract from macros. Like ALLHOSTS = ( a b c ................. z ) thisfile -> ${ALLHOSTS} - q + thathost Don't ask me how to implement this. This is only a dream. From mcooper%acamar.usc.edu@usc.edu Fri Aug 28 10:08:05 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA20349; Fri, 28 Aug 92 10:08:05 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA26164; Fri, 28 Aug 92 10:08:03 PDT Sender: "Michael A. Cooper" Date: Fri, 28 Aug 92 10:07:59 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: wish list In-Reply-To: Your message of Fri, 28 Aug 92 12:19 EDT Message-Id: > One thing that would be nice is to be able to add to and subtract from > macros. Like > > ALLHOSTS = ( a b c ................. z ) > > thisfile -> ${ALLHOSTS} - q + thathost > > Don't ask me how to implement this. This is only a dream. > If you build of your list of host macros you can get the same thing. i.e. A = (foo1 foo2) B = (bar1 bar2) ALL = (${A} ${B}) mike From wolman@crl.dec.com Fri Aug 28 10:55:30 1992 Return-Path: Received: from crl.dec.com by usc.edu (5.64+/SMI-3.0DEV3) id AA22260; Fri, 28 Aug 92 10:55:30 PDT Received: by crl.dec.com; id AA23380; Fri, 28 Aug 92 13:51:05 -0400 Received: by easynet.crl.dec.com; id AA01313; Fri, 28 Aug 92 13:55:23 -0400 Message-Id: <9208281755.AA01253@raritan.crl.dec.com> To: mcooper@usc.edu Cc: neal@ctd.comsat.com (Neal Becker), rdist@usc.edu Subject: Re: wish list In-Reply-To: Your message of Fri, 28 Aug 92 10:07:59 -0700. Date: Fri, 28 Aug 92 13:55:21 -0400 From: Alec Wolman X-Mts: smtp > If you build of your list of host macros you can get the same thing. > i.e. > > A = (foo1 foo2) > B = (bar1 bar2) > ALL = (${A} ${B}) > > mike Not exactly. The ability to subtract a single host from a long list is what is really useful. For example, if I rdist /etc/printcap to 50 clients, but 2 of those clients have local versions of printcap, then it is really useful to be able to say: /etc/printcap -> ${STDCLIENTS} - ( foo bar ) install; I don't want to construct the STDCLIENTS list by making STDCLIENTS = ( ${REALLYSTDCLIENTS} ${SPECIALPRINTCAP} ) because I probably use STDCLIENTS to distribute lots of other things, including sendmail.cf, ntp.conf, etc... each of which may have their own set of exceptions. Alec From rsalz@osf.org Fri Aug 28 11:37:14 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3) id AA23957; Fri, 28 Aug 92 11:37:14 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA04406; Fri, 28 Aug 92 14:37:11 -0400 Received: by earth.osf.org (5.64/4.7) id AA04589; Fri, 28 Aug 92 14:37:10 -0400 Date: Fri, 28 Aug 92 14:37:10 -0400 From: rsalz@osf.org Message-Id: <9208281837.AA04589@earth.osf.org> To: rdist@usc.edu Subject: Re: wish list I compiled, but didn't test this diff -- I'll leave that to Mike and the rest of you. :-) /r$ *** .orig/rdist.1 Fri Aug 28 14:08:45 1992 --- rdist.1 Fri Aug 28 14:33:12 1992 *************** *** 352,357 **** --- 352,371 ---- `(' `)' .fi + These simple lists can be modified by using one level of set addition + or subtraction like this: + .nf + + .ti +.5i + list '-' list + or + .ti +.5i + list '+' list + .fi + If additional modifications are needed (e.g., ``all servers and client + client machines except for the OSF/1 machines'') then the list will have + to be explicitly constructed in steps using "temporary" variables. + .PP The shell meta-characters `[', `]', `{', `}', `*', and `?' are recognized and expanded (on the local host only) in the same way as .IR csh (1). *** .orig/gram.y Fri Aug 28 14:08:44 1992 --- gram.y Fri Aug 28 14:29:04 1992 *************** *** 45,50 **** --- 45,51 ---- #include "defs.h" + static struct namelist *addnl(), *subnl(); struct cmd *cmds = NULL; struct cmd *last_cmd; struct namelist *last_n; *************** *** 79,85 **** %type OPTION, options %type NAME, STRING %type INSTALL, NOTIFY, EXCEPT, PATTERN, SPECIAL, CMDSPECIAL, cmdlist, cmd ! %type namelist, names, opt_namelist %% --- 80,86 ---- %type OPTION, options %type NAME, STRING %type INSTALL, NOTIFY, EXCEPT, PATTERN, SPECIAL, CMDSPECIAL, cmdlist, cmd ! %type namelist, names, opt_namelist nlist %% *************** *** 105,111 **** | error ; ! namelist: NAME = { $$ = makenl($1); } | LP names RP = { --- 106,117 ---- | error ; ! namelist: nlist { $$ = $1; } ! | nlist '-' nlist { $$ = subnl($1, $3); } ! | nlist '+' nlist { $$ = addnl($1, $3); } ! ; ! ! nlist: NAME = { $$ = makenl($1); } | LP names RP = { *************** *** 530,535 **** --- 536,593 ---- nl->n_name = name; nl->n_next = NULL; return(nl); + } + + + /* + ** join two namelists. + */ + static struct namelist * + addnl(n1, n2) + struct namelist *n1, *n2; + { + struct namelist *nl, *prev; + + for (prev = NULL; n1; n1 = n1->n_next, prev = nl) { + nl = makenl(n1->n_name); + nl->n_next = prev; + } + for (; n2; n2 = n2->n_next, prev = nl) { + nl = makenl(n2->n_name); + nl->n_next = prev; + } + return nl; + } + + /* + ** is the name p in the namelist nl? + */ + static int + innl(nl, p) + struct namelist *nl; + char *p; + { + for ( ; nl; nl = nl->n_next) + if (!strcmp(p, nl->n_name)) + return 1; + return 0; + } + + /* + ** copy n1 except for elements that are in n2. + */ + static struct namelist * + subnl(n1, n2) + struct namelist *n1, *n2; + { + struct namelist *nl, *prev; + + for (prev = NULL; n1; n1 = n1->n_next, prev = nl) + if (!innl(n2, n1->n_name)) { + nl = makenl(n1->n_name); + nl->n_next = prev; + } + return nl; } /* From mcooper%acamar.usc.edu@usc.edu Fri Aug 28 12:36:38 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA26328; Fri, 28 Aug 92 12:36:38 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA26336; Fri, 28 Aug 92 12:36:35 PDT Sender: "Michael A. Cooper" Date: Fri, 28 Aug 92 12:36:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Alec Wolman Cc: neal@ctd.comsat.com (Neal Becker), rdist@usc.edu Subject: Re: wish list In-Reply-To: Your message of Fri, 28 Aug 92 13:55:21 -0400 Message-Id: I think I understand now. I'll put it on my TODO list. If someone wants to save me the time, feel free. mike From ken@uunet.uu.net Fri Aug 28 13:49:39 1992 Return-Path: Received: from rodan.UU.NET by usc.edu (5.64+/SMI-3.0DEV3) id AA29346; Fri, 28 Aug 92 13:49:39 PDT Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA12093; Fri, 28 Aug 92 16:49:34 -0400 From: ken@uunet.uu.net (Ken Dahl) Message-Id: <9208282049.AA12093@rodan.UU.NET> Subject: bug in groups checking To: rdist@usc.edu Date: Fri, 28 Aug 92 16:49:33 EDT X-Mailer: ELM [version 2.3 PL10] We started using rdist to copy around some config files and binaries on our news systems and had rdist erroneously clear the setgid bits on some programs: > news1: chmod: /usr/local/lib/newsbin from 775 to 2775 > news1: removed: /usr/local/lib/newsbin/newsrun > news1: chmod: /usr/local/lib/newsbin/batch from 775 to 2775 > news1: updated: /usr/local/lib/newsbin/batch/batchsm > news1: chmod: /usr/local/lib/newsbin/expire from 775 to 2775 > news1: chmod: /usr/local/lib/newsbin/input from 775 to 2775 > news1: chmod: /usr/local/lib/newsbin/input/RCS from 775 to 2775 > news1: updated: /usr/local/lib/newsbin/input/newsrun.old > news1: chmod: /usr/local/lib/newsbin/relay from 775 to 2775 > news1: removed: /usr/local/lib/newsbin/relay/explode.pre-T > news1: user news not in group news, clearing setgid This is wrong. news is in group news by virtue of its passwd entry: [ken@news1(tcsh):97] groups news news : ftp news The code in server.c is only looking at the group file entry. An additional check of pw->pw_gid appears in order. -- Ken Dahl ken@uunet.uu.net UUNET Technologies, Inc. ...!uunet!ken From mcooper%acamar.usc.edu@usc.edu Fri Aug 28 16:38:37 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA06527; Fri, 28 Aug 92 16:38:37 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3) id AA27436; Fri, 28 Aug 92 16:38:33 PDT Sender: "Michael A. Cooper" Date: Fri, 28 Aug 92 16:38:29 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: ken@uunet.uu.net (Ken Dahl) Cc: rdist@usc.edu Subject: Re: bug in groups checking In-Reply-To: Your message of Fri, 28 Aug 92 16:49:33 EDT Message-Id: > We started using rdist to copy around some config files and binaries on > our news systems and had rdist erroneously clear the setgid bits on some > programs: > > > news1: chmod: /usr/local/lib/newsbin from 775 to 2775 > > news1: removed: /usr/local/lib/newsbin/newsrun > > news1: chmod: /usr/local/lib/newsbin/batch from 775 to 2775 > > news1: updated: /usr/local/lib/newsbin/batch/batchsm > > news1: chmod: /usr/local/lib/newsbin/expire from 775 to 2775 > > news1: chmod: /usr/local/lib/newsbin/input from 775 to 2775 > > news1: chmod: /usr/local/lib/newsbin/input/RCS from 775 to 2775 > > news1: updated: /usr/local/lib/newsbin/input/newsrun.old > > news1: chmod: /usr/local/lib/newsbin/relay from 775 to 2775 > > news1: removed: /usr/local/lib/newsbin/relay/explode.pre-T > > news1: user news not in group news, clearing setgid > > This is wrong. news is in group news by virtue of its passwd entry: > > [ken@news1(tcsh):97] groups news > news : ftp news > > The code in server.c is only looking at the group file entry. An > additional check of pw->pw_gid appears in order. > > -- > Ken Dahl ken@uunet.uu.net > UUNET Technologies, Inc. ...!uunet!ken > Fixed. mike *** /tmp/T0a27427 Fri Aug 28 16:37:02 1992 --- server.c Fri Aug 28 16:36:28 1992 *************** *** 32,38 **** */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 6.25 1992/08/05 23:17:48 mcooper Exp $"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; --- 32,38 ---- */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 6.26 1992/08/28 23:35:39 mcooper Exp mcooper $"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; *************** *** 70,76 **** { static struct group *gr = NULL; register int i; ! int uid, gid; extern char *locuser; extern int userid; --- 70,76 ---- { static struct group *gr = NULL; register int i; ! int uid, gid, primegid = -2; extern char *locuser; extern int userid; *************** *** 89,96 **** } } else uid = pw->pw_uid; ! } else uid = pw->pw_uid; if (*group == ':') { gid = atoi(group + 1); goto ok; --- 89,98 ---- } } else uid = pw->pw_uid; ! } else { uid = pw->pw_uid; + primegid = pw->pw_gid; + } if (*group == ':') { gid = atoi(group + 1); goto ok; *************** *** 116,123 **** } else gid = gr->gr_gid; ! if (userid && gid >= 0) { ! if (gr) for (i = 0; gr->gr_mem[i] != NULL; i++) if (strcmp(locuser, gr->gr_mem[i]) == 0) goto ok; --- 118,125 ---- } else gid = gr->gr_gid; ! if (userid && gid >= 0 && gid != primegid) { ! if (gr) for (i = 0; gr->gr_mem[i] != NULL; i++) if (strcmp(locuser, gr->gr_mem[i]) == 0) goto ok; From torek@horse.ee.lbl.gov Fri Aug 28 18:28:12 1992 Return-Path: Received: from horse.ee.lbl.gov by usc.edu (5.64+/SMI-3.0DEV3) id AA10232; Fri, 28 Aug 92 18:28:12 PDT Received: by horse.ee.lbl.gov for rdist@usc.edu (5.65/1.41) id AA29098; Fri, 28 Aug 92 18:26:17 -0700 Message-Id: <9208290126.AA29098@horse.ee.lbl.gov> To: rsalz@osf.org Cc: rdist@usc.edu Subject: Re: wish list In-Reply-To: Your message of Fri, 28 Aug 92 14:37:10 -0400. <9208281837.AA04589@earth.osf.org> Date: Fri, 28 Aug 92 18:26:16 PDT From: Chris Torek If this is to be set union and exclusion (and where is intersection then? :-) ), rich's code should beware of things like A = (a b c) B = (c d e) $A + $B lest this produce (a b c c d e) For the mathematician in us, exclusion should also be spelled `\', :-) Chris From jmalcolm@sura.net Thu Sep 3 13:05:15 1992 Return-Path: Received: from cthulhu.sura.net by usc.edu (5.64+/SMI-3.0DEV3) id AA24920; Thu, 3 Sep 92 13:05:15 PDT Received: by cthulhu.sura.net (5.65b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA13580; Thu, 3 Sep 92 16:05:06 -0400 Date: Thu, 3 Sep 92 16:05:06 -0400 Message-Id: <9209032005.AA13580@cthulhu.sura.net> To: rdist@usc.edu Subject: behavior of new rdist with -w From: "Joseph Malcolm" Sender: jmalcolm@sura.net Under the old rdist, this rdist file: HOSTS = ( bogus ) FILES = ( /usr/local ) ${FILES} -> ${HOSTS} install -R -w /tmp/local ; notify jmalcolm; would mirror /usr/local into bogus:/tmp/local, i.e., /usr/local/bin -> bogus:/tmp/local/bin, /usr/local/lib -> bogus:/tmp/local/lib, etc. With the new rdist (6.0beta pl3), it now mirrors /usr/local into bogus:/tmp/local/usr/local, which is not what I want. Is there a way of getting the old behavior in the new rdist? From mcooper@acamar.usc.edu Fri Sep 11 19:25:33 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA27150; Fri, 11 Sep 92 19:25:33 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA11340; Fri, 11 Sep 92 19:25:23 PDT Sender: "Michael A. Cooper" Date: Fri, 11 Sep 92 19:25:20 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "Joseph Malcolm" Cc: rdist@usc.edu Subject: Re: behavior of new rdist with -w In-Reply-To: Your message of Thu, 3 Sep 92 16:05:06 -0400 Message-Id: > Under the old rdist, this rdist file: > > HOSTS = ( bogus ) > > FILES = ( /usr/local ) > > ${FILES} -> ${HOSTS} > install -R -w /tmp/local ; > notify jmalcolm; > > would mirror /usr/local into bogus:/tmp/local, i.e., /usr/local/bin -> > bogus:/tmp/local/bin, /usr/local/lib -> bogus:/tmp/local/lib, etc. > > With the new rdist (6.0beta pl3), it now mirrors /usr/local into > bogus:/tmp/local/usr/local, which is not what I want. > > Is there a way of getting the old behavior in the new rdist? > > I don't know which old rdist you are using, but the original one that I have from SunOS 4.1.1 does the same thing as 6.0beta.3. If you want the behavior you describe, don't use -w: ${FILES} -> ${HOSTS} install -R /tmp/local ; mike From jmalcolm@sura.net Mon Sep 14 16:13:14 1992 Return-Path: Received: from darwin.sura.net by usc.edu (5.64+/SMI-3.0DEV3) id AA09220; Mon, 14 Sep 92 16:13:14 PDT Received: by darwin.sura.net for rdist@usc.edu id AA29498 (5.65b/(SURAnet $Revision: 1.27 $)); Mon, 14 Sep 92 19:13:09 -0400 Date: Mon, 14 Sep 92 19:13:09 -0400 Message-Id: <9209142313.AA29498@darwin.sura.net> To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: on Fri, 11 Sep 92 19:25:20 PDT References: Subject: Re: behavior of new rdist with -w From: "Joseph Malcolm" Sender: jmalcolm@sura.net [bogus information from me deleted.] >I don't know which old rdist you are using, but the original one >that I have from SunOS 4.1.1 does the same thing as 6.0beta.3. >If you want the behavior you describe, don't use -w: > >${FILES} -> ${HOSTS} > install -R /tmp/local ; > > mike You are entirely correct, and I apologize for not checking my facts before asking the list. However, I believe the description of the -w option could be improved. Currently the man page reads: -w Whole mode. The whole file name is appended to the des- tination directory name. Normally, only the last com- ponent of a name is used when renaming files. This will preserve the directory structure of the files being copied instead of flattening the directory struc- ture. For example, renaming a list of files such as ( dir1/f1 dir2/f2 ) to dir3 would create files dir3/dir1/f1 and dir3/dir2/f2 instead of dir3/f1 and dir3/f2. which, at least to me, implies that without the -w flag the tree structure of the hierarchy being rdisted will be lost (or "flattened", as the man page says.) But that is not what actually happens. (yes, I checked this time.) From mcooper@acamar.usc.edu Mon Sep 14 18:51:41 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA16175; Mon, 14 Sep 92 18:51:41 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA13801; Mon, 14 Sep 92 18:51:39 PDT Sender: "Michael A. Cooper" Date: Mon, 14 Sep 92 18:51:37 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Version 6.0beta.4 available Message-Id: Version 6.0beta.4 is now out for ftp on usc.edu as /pub/rdist/rdist.tar.Z. The list of changes are detailed below. A copy of my paper on rdist for USENIX LISA VI next month is also out for ftp as /pub/rdist/overhaul.ps.Z. The final paper "went to press" last week. mike From mcooper%acamar.usc.edu@usc.edu Mon Sep 14 18:52:15 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA16223; Mon, 14 Sep 92 18:52:15 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA13673; Mon, 14 Sep 92 18:33:27 PDT Sender: "Michael A. Cooper" Date: Mon, 14 Sep 92 18:33:24 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "Joseph Malcolm" Cc: rdist@usc.edu Subject: Re: behavior of new rdist with -w In-Reply-To: Your message of Mon, 14 Sep 92 19:13:09 -0400 Message-Id: I clarified the descrioption of -w in rdist.1. Thanks for pointing this out. mike From mcooper@acamar.usc.edu Mon Sep 14 18:52:43 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA16246; Mon, 14 Sep 92 18:52:43 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA13807; Mon, 14 Sep 92 18:52:41 PDT Sender: "Michael A. Cooper" Date: Mon, 14 Sep 92 18:52:39 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Re: Version 6.0beta.4 available Message-Id: Forgot the changes... mike Mon Sep 14 12:52:32 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.0beta.4 * Add note to README about AIX bsdcc stanza. * Clarify -w description in rdist.1. * Include target name in error msg "no files to be updated". Fri Sep 11 14:04:45 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fixed a bug in rdistd which caused set[ug]id bits to not be cleared when they were suppose to be, even when it said it was being cleared. The mode of a file/directory would also not be set in certain cases. This bug looks to date back to the original version. * Add support for macro list addition and subtraction (Rich Salz). * Make having statfs() configurable with HAVE_STATFS (Rich Salz). * Define HPUX if __hpux is defined and change things to use HPUX. * Make the type of directory struct used configurable (Rich Salz). Tue Sep 1 14:46:00 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix another case of setgid being stripped when the owner's primary (passwd) gid == file group owner. (Ken Dahl) * Change "Don't know how to rdist to ..." to be "Label ... is not defined in the distfile." for clarity. Mon Aug 31 15:08:26 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Change "register char i" to "register int i" in docmd(). * Fixed another bug with "Don't know how to rdist to ...". This time, a much simplier approach was taken to remove the "unused" stuff from the last fix. * Save argc and argv from main() into realargc and realargv before setargs() overwrites. Fri Aug 28 16:36:34 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * The primary group of the owner of a file was not being checked in fchog(), which resulted in the setgid bit being cleared. Thu Aug 27 13:33:35 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fixed typo in config.h that disabled SETARGS. * Make _PATH_OLDRDIST compatibility actually work. Also do logging via logmsg() and fatal() for compat stuff. * Fatal() error msgs are now logged to logmsg(LOG_ERR, ...) for rdistd * Strip leading path of progname. Mon Aug 10 15:33:22 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Update wording on old rcmd() bug in README. (Rich) Thu Aug 6 09:59:58 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix ISEXEC define in isexec.c. (Neal Becker) From neal@ctd.comsat.com Tue Sep 15 05:16:42 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA05328; Tue, 15 Sep 92 05:16:42 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUbpe-0003TdC; Tue, 15 Sep 92 08:16 EDT Message-Id: Date: Tue, 15 Sep 92 08:16 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu Subject: rdist 6.0b4 on hpux install bug In-Reply-To: References: In defs.h config.h is included after test for HPUX, but unless you set -DHPUX in Makefile HPUX is not defined until config.h is included. From neal@ctd.comsat.com Tue Sep 15 08:11:27 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA11118; Tue, 15 Sep 92 08:11:27 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUeYn-0003TdC; Tue, 15 Sep 92 11:11 EDT Message-Id: Date: Tue, 15 Sep 92 11:11 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu Subject: Use of list - list -> BUS ERROR I just had to try the new list - list stuff. Here's my distfile: ------------------------------------------------ CAEHOSTS = ( picard laforge data worf riker ) IMGHOSTS = ( eightman flyhalf fullback hooker nyquist ) SIMHOSTS = ( fft chekov neal bugs daffy speedy wiley foghorn peppy sylvestr elmer tweety yosemite roadrunr porky ) ALLHOSTS = ( ${CAEHOSTS} ${IMGHOSTS} ${SIMHOSTS} ) COMMONFILES = ( /usr/adm/inetd.sec /local/maps /etc/hosts.equiv /usr/lib/aliases /etc/services /etc/inetd.conf /etc/netgroup /etc/hosts /local/etc/{adjtimed,amd,amq,batchd,imapd,ipop2d,ipop3d,ntalkd,xntpd,xntpdc,ntpq,in.identd,gopherd,gindexd,gopherls} /etc/hesiod.conf /etc/syslog.conf ) common: ${COMMONFILES} -> ${ALLHOSTS} install ; special /usr/lib/aliases "newaliases"; special /etc/inetd.conf "/etc/inetd -c"; SIMPWFILES = ( /etc/passwd /etc/group /.secure/etc/passwd /.rhosts ) simpasswd: ${SIMPWFILES} -> ${SIMHOSTS} install; NTPOTHERHOSTS = ${ALLHOSTS} - ( fft flyhalf picard ) /local/rdist/ntp/other/xntp.conf -> ${NTPOTHERHOSTS} install /local/etc/xntp.conf; /local/rdist/ntp/fft/xntp.conf -> fft install /local/etc/xntp.conf; /local/rdist/ntp/flyhalf/xntp.conf -> flyhalf install /local/etc/xntp.conf; /local/rdist/ntp/picard/xntp.conf -> picard install /local/etc/xntp.conf; ------------------------------------------ Here's what I get: ----------------------------------------- rdist -D -v -f /local/rdist/distfile makenl(picard) makenl(laforge) makenl(data) makenl(worf) makenl(riker) lookup(CAEHOSTS, 1, 400113f0) makenl(eightman) makenl(flyhalf) makenl(fullback) makenl(hooker) makenl(nyquist) lookup(IMGHOSTS, 1, 400114c8) makenl(fft) makenl(chekov) makenl(neal) makenl(bugs) makenl(daffy) makenl(speedy) makenl(wiley) makenl(foghorn) makenl(peppy) makenl(sylvestr) makenl(elmer) makenl(tweety) makenl(yosemite) makenl(roadrunr) makenl(porky) lookup(SIMHOSTS, 1, 400115a0) makenl(${CAEHOSTS}) makenl(${IMGHOSTS}) makenl(${SIMHOSTS}) lookup(ALLHOSTS, 1, 400117d0) makenl(/usr/adm/inetd.sec) makenl(/local/maps) makenl(/etc/hosts.equiv) makenl(/usr/lib/aliases) makenl(/etc/services) makenl(/etc/inetd.conf) makenl(/etc/netgroup) makenl(/etc/hosts) makenl(/local/etc/{adjtimed,amd,amq,batchd,imapd,ipop2d,ipop3d,ntalkd,xntpd,xntpdc,ntpq,in.identd,gopherd,gindexd,gopherls}) makenl(/etc/hesiod.conf) makenl(/etc/syslog.conf) lookup(COMMONFILES, 1, 40011880) makenl(${COMMONFILES}) makenl(${ALLHOSTS}) makenl(/usr/lib/aliases) expand(40011b80, 7) list = ( /usr/lib/aliases ) makenl() expanded list = ( /usr/lib/aliases ) makenl(/etc/inetd.conf) expand(40011c10, 7) list = ( /etc/inetd.conf ) makenl() expanded list = ( /etc/inetd.conf ) insert(common, 40011ae8, 40011b10, 40011b20) files = ( ${COMMONFILES} ) expand(40011ae8, 3) list = ( ${COMMONFILES} ) lookup(COMMONFILES, 0, 0) makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() expanded list = ( /usr/adm/inetd.sec /local/maps /etc/hosts.equiv /usr/lib/aliases /etc/services /etc/inetd.conf /etc/netgroup /etc/hosts /local/etc/adjtimed /local/etc/amd /local/etc/amq /local/etc/batchd /local/etc/imapd /local/etc/ipop2d /local/etc/ipop3d /local/etc/ntalkd /local/etc/xntpd /local/etc/xntpdc /local/etc/ntpq /local/etc/in.identd /local/etc/gopherd /local/etc/gindexd /local/etc/gopherls /etc/hesiod.conf /etc/syslog.conf ) expand(40011b10, 7) list = ( ${ALLHOSTS} ) lookup(ALLHOSTS, 0, 0) lookup(CAEHOSTS, 0, 0) lookup(IMGHOSTS, 0, 0) lookup(SIMHOSTS, 0, 0) makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() expanded list = ( picard laforge data worf riker eightman flyhalf fullback hooker nyquist fft chekov neal bugs daffy speedy wiley foghorn peppy sylvestr elmer tweety yosemite roadrunr porky ) makenl(/etc/passwd) makenl(/etc/group) makenl(/.secure/etc/passwd) makenl(/.rhosts) lookup(SIMPWFILES, 1, 40012420) makenl(${SIMPWFILES}) makenl(${SIMHOSTS}) insert(simpasswd, 40012778, 400127a0, 400127b0) files = ( ${SIMPWFILES} ) expand(40012778, 3) list = ( ${SIMPWFILES} ) lookup(SIMPWFILES, 0, 0) makenl() makenl() makenl() makenl() expanded list = ( /etc/passwd /etc/group /.secure/etc/passwd /.rhosts ) expand(400127a0, 7) list = ( ${SIMHOSTS} ) lookup(SIMHOSTS, 0, 0) makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() expanded list = ( fft chekov neal bugs daffy speedy wiley foghorn peppy sylvestr elmer tweety yosemite roadrunr porky ) makenl(${ALLHOSTS}) makenl(fft) makenl(flyhalf) makenl(picard) expand(40012a78, 1) list = ( ${ALLHOSTS} ) lookup(ALLHOSTS, 0, 0) lookup(CAEHOSTS, 0, 0) lookup(IMGHOSTS, 0, 0) lookup(SIMHOSTS, 0, 0) makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() makenl() expanded list = ( picard laforge data worf riker eightman flyhalf fullback hooker nyquist fft chekov neal bugs daffy speedy wiley foghorn peppy sylvestr elmer tweety yosemite roadrunr porky ) expand(40012c28, 1) list = ( fft flyhalf picard ) makenl() makenl() makenl() expanded list = ( fft flyhalf picard ) makenl(laforge) makenl(data) makenl(worf) makenl(riker) makenl(eightman) makenl(fullback) makenl(hooker) makenl(nyquist) makenl(chekov) makenl(neal) makenl(bugs) makenl(daffy) makenl(speedy) makenl(wiley) makenl(foghorn) makenl(peppy) makenl(sylvestr) makenl(elmer) makenl(tweety) makenl(yosemite) makenl(roadrunr) makenl(porky) lookup(NTPOTHERHOSTS, 1, 40013170) makenl(/local/rdist/ntp/other/xntp.conf) makenl(${NTPOTHERHOSTS}) makenl(/local/etc/xntp.conf) expand(40013248, 1) list = ( /local/etc/xntp.conf ) makenl() expanded list = ( /local/etc/xntp.conf ) insert(, 400131c8, 400131f8, 40013208) files = ( /local/rdist/ntp/other/xntp.conf ) expand(400131c8, 3) list = ( /local/rdist/ntp/other/xntp.conf ) makenl() expanded list = ( /local/rdist/ntp/other/xntp.conf ) expand(400131f8, 7) list = ( ${NTPOTHERHOSTS} ) lookup(NTPOTHERHOSTS, 0, 0) Bus error (core dumped) ----------------------------------------------- Any ideas? (Sorry the example is so long). From neal@ctd.comsat.com Tue Sep 15 08:36:57 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA11754; Tue, 15 Sep 92 08:36:57 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUexM-0003TdC; Tue, 15 Sep 92 11:36 EDT Message-Id: Date: Tue, 15 Sep 92 11:36 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist@usc.edu Subject: Re: Use of list - list -> BUS ERROR Here's a stack dump to go with the previous: (I don't really understand this code, so I hope someone else does) 0 expstr (s = 0x400131b0) [expand.c: 184] cp = 0x400131b2 cp1 = 0x00000014 tp = 0x00000029 tail = 0x400131c0 ebuf = 0x68fada70 savec = 0 oeargc = 0 1 expand (list = 0x400131d0, wh = 7) [expand.c: 122] nl = 0x400131d0 prev = 0x400132a8 n = 1 pathbuf = 0x68fad5fc cp = 0x68fad334 2 insert (label = 00000000, files = 0x400132a8, hosts = 0x400131d0, subcmds = 0x400131e0) [gram.y: 436] c = 0x68fad344 prev = 0x68fad334 nc = 0x40012bc8 h = 00000000 lasth = 0x40012a50 3 yyparse () [gram.y: 99] yypvt = 0x40004710 yy_pv = 0x40004700 yy_ps = 0x40004958 yy_state = 2 yy_n = 9 yyxi = 00000000 yy_len = 4 nl = 0x40013250 nl = 0x8007eb97 cp = 0x00004ae7 4 main (argc = 3, argv = 0x68fad334, envp = 0x68fad344) [rdist.c: 258] x = 3 dsthosts = 00000000 dsthostc = 0 cmdargs = 0 c = -1 > We died at line 184 in expand.c. The struct tp returned from lookup is apparantly garbage. print tp >tp = 0x00000029 This is a rather suspicious-looking address! From neal@ctd.comsat.com Tue Sep 15 09:18:05 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA13578; Tue, 15 Sep 92 09:18:05 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUfbF-0003TdC; Tue, 15 Sep 92 12:18 EDT Message-Id: Date: Tue, 15 Sep 92 12:18 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu Subject: Re: rdist BUS ERROR in list-list This code (in gram.y) looks suspicious: static struct namelist * subnl(n1, n2) struct namelist *n1, *n2; { struct namelist *nl, *prev; n1 = expand(n1, E_VARS); n2 = expand(n2, E_VARS); for (prev = NULL; n1; n1 = n1->n_next, prev = nl) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; } return(nl); } Is nl always set? Should this be more like: for (prev = NULL; n1; n1 = n1->n_next) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; prev = nl; } return(nl); Thanks. From rsalz@osf.org Tue Sep 15 09:26:43 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3) id AA13956; Tue, 15 Sep 92 09:26:43 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA17516; Tue, 15 Sep 92 12:26:37 -0400 Received: by earth.osf.org (5.64/4.7) id AA24509; Tue, 15 Sep 92 12:26:36 -0400 Date: Tue, 15 Sep 92 12:26:36 -0400 From: rsalz@osf.org Message-Id: <9209151626.AA24509@earth.osf.org> To: mcooper@usc.edu, neal@ctd.comsat.com Subject: Re: rdist BUS ERROR in list-list Cc: rdist@usc.edu > return(nl); I think this should be "return(prev);" From neal@ctd.comsat.com Tue Sep 15 09:50:16 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA14999; Tue, 15 Sep 92 09:50:16 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUg6N-0003TdC; Tue, 15 Sep 92 12:50 EDT Message-Id: Date: Tue, 15 Sep 92 12:50 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist@usc.edu Subject: Re: rdist BUS ERROR in list-list SOLVED! In-Reply-To: References: Here's a patch. This appears to have solved my problem. *** /hosts/flyhalf/images/src/rdist-6.0beta.4/gram.y Fri Sep 11 17:33:49 1992 --- gram.y Tue Sep 15 12:44:49 1992 *************** *** 599,610 **** n1 = expand(n1, E_VARS); n2 = expand(n2, E_VARS); ! for (prev = NULL; n1; n1 = n1->n_next, prev = nl) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; } ! return(nl); } /* --- 599,611 ---- n1 = expand(n1, E_VARS); n2 = expand(n2, E_VARS); ! for (prev = NULL; n1; n1 = n1->n_next) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; + prev = nl; } ! return(prev); } /* From neal@ctd.comsat.com Tue Sep 15 10:12:18 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3) id AA16242; Tue, 15 Sep 92 10:12:18 PDT Received: by neal.ctd.comsat.com (Smail3.1.27.1 #2) id m0mUgRg-0003TdC; Tue, 15 Sep 92 13:12 EDT Message-Id: Date: Tue, 15 Sep 92 13:12 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist@usc.edu Subject: Re: rdist BUS ERROR in list-list SOLVED! In-Reply-To: References: Whoops! Missed something. The same error occurs in addnl() as well, so here's a complete patch: *** /hosts/flyhalf/images/src/rdist-6.0beta.4/gram.y Fri Sep 11 17:33:49 1992 --- gram.y Tue Sep 15 13:04:32 1992 *************** *** 580,591 **** nl = makenl(n1->n_name); nl->n_next = prev; } ! for (; n2; n2 = n2->n_next, prev = nl) if (!innl(nl, n2->n_name)) { nl = makenl(n2->n_name); nl->n_next = prev; } ! return(nl); } /* --- 580,592 ---- nl = makenl(n1->n_name); nl->n_next = prev; } ! for (; n2; n2 = n2->n_next) if (!innl(nl, n2->n_name)) { nl = makenl(n2->n_name); nl->n_next = prev; + prev = nl; } ! return(prev); } /* *************** *** 599,610 **** n1 = expand(n1, E_VARS); n2 = expand(n2, E_VARS); ! for (prev = NULL; n1; n1 = n1->n_next, prev = nl) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; } ! return(nl); } /* --- 600,612 ---- n1 = expand(n1, E_VARS); n2 = expand(n2, E_VARS); ! for (prev = NULL; n1; n1 = n1->n_next) if (!innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; + prev = nl; } ! return(prev); } /* From mcooper@acamar.usc.edu Tue Sep 15 10:11:39 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA16190; Tue, 15 Sep 92 10:11:39 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA14414; Tue, 15 Sep 92 10:11:36 PDT Sender: "Michael A. Cooper" Date: Tue, 15 Sep 92 10:11:33 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: rdist 6.0b4 on hpux install bug In-Reply-To: Your message of Tue, 15 Sep 92 08:16 EDT Message-Id: How's this? mike *** /tmp/T0a14404 Tue Sep 15 10:09:50 1992 --- /tmp/T1a14404 Tue Sep 15 10:09:51 1992 *************** *** 34,40 **** */ /* ! * $Id: defs.h,v 6.32 1992/09/11 21:09:45 mcooper Exp $ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ --- 34,40 ---- */ /* ! * $Id: defs.h,v 6.33 1992/09/15 17:04:10 mcooper Exp $ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ *************** *** 46,54 **** #include #include #include - #if defined(HPUX) - #include - #endif /* defined(HPUX) */ #include #include #include --- 46,51 ---- *************** *** 58,70 **** #include "config.h" #include "configdata.h" #include "pathnames.h" #ifndef yacc #include "y.tab.h" #endif ! #ifdef HAVE_VARARGS #include ! #endif /* boolean truth */ #ifndef TRUE --- 55,72 ---- #include "config.h" #include "configdata.h" #include "pathnames.h" + #ifndef yacc #include "y.tab.h" #endif ! #if defined(HPUX) ! #include ! #endif /* defined(HPUX) */ ! ! #if defined(HAVE_VARARGS) #include ! #endif /* defined(HAVE_VARARGS) */ /* boolean truth */ #ifndef TRUE From mcooper@acamar.usc.edu Tue Sep 15 10:12:05 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA16212; Tue, 15 Sep 92 10:12:05 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA14417; Tue, 15 Sep 92 10:12:01 PDT Sender: "Michael A. Cooper" Date: Tue, 15 Sep 92 10:11:58 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: rdist BUS ERROR in list-list SOLVED! In-Reply-To: Your message of Tue, 15 Sep 92 12:50 EDT Message-Id: Thanks. mike From mcooper@acamar.usc.edu Tue Sep 15 10:54:43 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA18335; Tue, 15 Sep 92 10:54:43 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA14609; Tue, 15 Sep 92 10:54:41 PDT Sender: "Michael A. Cooper" Date: Tue, 15 Sep 92 10:54:38 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Rdist 6.0beta.5 Message-Id: I just put out 6.0beta.5. This release just contains Neal's fixes for list subtraction/addition and the defs.h fix for HPUX. mike From mcooper@acamar.usc.edu Tue Sep 15 12:37:38 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA23504; Tue, 15 Sep 92 12:37:38 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA14677; Tue, 15 Sep 92 12:37:36 PDT Sender: "Michael A. Cooper" Date: Tue, 15 Sep 92 12:37:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Overhaul of message handling Message-Id: I'm getting ready to overhaul message handling in rdist. Here are some of my thoughts. The intent is for rdist to provide a basic level of message "routing" and selection of messages. A good filter script would continue to be the best means of parsing a large amount of output for human consumption. The messages from rdist should be human readable as they appear without outside filtering. Comments? mike FACILITIES Messages can be sent to any number of message facilities. The facilities are determined at program start time. Messages can be sent to any number of these facilities: - logfile: could be one of Path name of file - Standard output (stdout) - syslog TYPE Every message has a TYPE. The list of TYPEs that are sent to each facility is determined at start time. The user can control exactly what types of messages are seen and what are not. The TYPEs are: DEBUG Debugging NERROR Normal errors FERROR Fatal errors WARNING Warnings - things that are not quite errors CHANGE Messages about any type of change INFO General info messages ALL All of the above FORMAT Messages will be of two forms - normal and error. Normal messages will be of format: : The name of the host the message originated from. What the action was that resulted in message. Should be just one word (no white space). i.e. "installed", "updated", "chmod", "mkdir", "error", "warning" The name of the file/directory that is related to. Any additional text for the message. This could be a description of the error. Sample output: sargas: updating /etc/termcap nova: chmod /usr/bin from 777 to 755 calvin: need to update /etc/rc.boot Error messages will be of format: : : : The name of the host the message originated from. "local" == originate from local "rdist" program. "remote" == originate from remote "rdistd" program. What the action was that resulted in message. i.e. "installed", "updated", "chmod", "mkdir", "error", "warning" The name of the file/directory that is related to. This field is optional. Description of error. Sample output: skat: REMOTE ERROR: /usr/lib/tmac: opendir failed: No such file or directory zync: REMOTE ERROR: /usr/tmp/foobar: not a plain file sin: REMOTE ERROR: Unknown cmdspecial command 'skin' sol: LOCAL ERROR: Connection timed out Questions: How should local errors relating to something like syntax errors in the distfile be displayed? rdist: Syntax error in distfile line 12 or localhost: LOCAL ERROR: Syntax error in distfile line 12 CONTROL The FACILITIES and TYPEs will be controlled via command line options to rdist: -M stdout=change,nerror,ferror -M syslog=all This says to log change, nerror, ferror to stdout and log everything (all) to syslog. This is for "rdist". -L syslog=nerror,info This says to log normal error and info to syslog on the remote (server) host where rdistd is run. From ken@uunet.uu.net Wed Sep 16 14:14:11 1992 Return-Path: Received: from rodan.UU.NET by usc.edu (5.64+/SMI-3.0DEV3) id AA06290; Wed, 16 Sep 92 14:14:11 PDT Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21763; Wed, 16 Sep 92 17:14:10 -0400 From: ken@uunet.uu.net (Ken Dahl) Message-Id: <9209162114.AA21763@rodan.UU.NET> Subject: LOCAL ERROR in rdist To: rdist@usc.edu (rdist 6.0 beta list) Date: Wed, 16 Sep 92 17:14:09 EDT X-Mailer: ELM [version 2.3 PL10] I sometimes (often) get "LOCAL ERROR: /tmp/rdista16436: No such file or directory" when running rdist with multiple children updaters. With -M1 or -F it never appears. The PID part of the filename changes of course, and the hosts vary somewhat, so it isn't perfectly consistent. Has anyone else noticed this? Debugging output doesn't reveal anything, at least not to me. Looking through the code, I see that doarrow() in docmd.c has a signal handler that calls cleanup() on SIGPIPE and also has an unlink(tempfile) call in it. Can both of these get called? Do children try to unlink the tempfile? -- Ken Dahl ken@uunet.uu.net UUNET Technologies, Inc. ...!uunet!ken From mcooper@acamar.usc.edu Wed Sep 16 16:53:04 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA15841; Wed, 16 Sep 92 16:53:04 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA03919; Wed, 16 Sep 92 16:53:01 PDT Sender: "Michael A. Cooper" Date: Wed, 16 Sep 92 16:52:58 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: ken@uunet.uu.net (Ken Dahl) Cc: rdist@usc.edu (rdist 6.0 beta list) Subject: Re: LOCAL ERROR in rdist In-Reply-To: Your message of Wed, 16 Sep 92 17:14:09 EDT Message-Id: I think this should fix that. mike *** /tmp/T0a03901 Wed Sep 16 16:51:14 1992 --- /tmp/T1a03901 Wed Sep 16 16:51:15 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 6.38 1992/08/31 22:11:43 mcooper Exp $"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 6.39 1992/09/16 23:49:03 mcooper Exp $"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; *************** *** 247,253 **** if (dosetreuid(0, userid) != 0) exit(1); - (void) mktemp(tempfile); if (cmdargs) docmdargs(realargc - optind, &realargv[optind]); --- 247,252 ---- *** /tmp/T0a03905 Wed Sep 16 16:51:50 1992 --- /tmp/T1a03905 Wed Sep 16 16:51:51 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.32 1992/09/16 23:47:55 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.31 1992/09/14 19:52:06 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 773,779 **** setproctitle("update %s", currenthost); #endif /* SETARGS */ } - (void) mktemp(tempfile); switch (cmd->c_type) { case ARROW: --- 773,778 ---- From wls@astro.UMD.EDU Thu Sep 17 11:35:41 1992 Received: from astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3++) id AA02703; Thu, 17 Sep 92 11:35:41 PDT Return-Path: Received: by astro.astro.umd.edu (5.65c/5.61sWLS) id AA16165; Thu, 17 Sep 1992 14:05:12 -0400 Date: Thu, 17 Sep 1992 14:05:12 -0400 From: wls@astro.UMD.EDU Message-Id: <199209171805.AA16165@astro.astro.umd.edu> To: rdist@usc.edu Subject: special & cmdspecial in :: construction Here are the patches to rdist6.0-beta5 to make the "special" and "cmdspecial" commands work in :: constructions. On the way a couple bugs are fixed. Why would you want these commands to work in doublecolon constructions? At the moment you can do two things with a :: construction: 1) list which files are newer on the standard output. 2) mail this list to someone. This very much limits the usefulness of the :: construction. Here is an example of the use of a "special" command in a :: construction. At UMCP astronomy we maintain files in which part of the file stays the same on all hosts while another part can vary. A "special" on a :: construction extracts the master part of the file. Then the master part is propagated to the other hosts with a standard "->" construction and another "special" command there forms the new file out of the master and the local part of the old file. Some bugs fixed: 1) in dodcolon() in docmd.c a pointer to a timeval struct was passed to setfiletime() rather than a time_t value. This caused the time of the timestamp to be set to very strange times rather than current time. The :: contruction did not work right with this bug. 2) In line 431 of docmd.c in routine doarrow() there is the code segment for (f = files; f != NULL; f = f->n_next) { if (filev) { for (cpp = filev; *cpp; cpp++) if (strcmp(f->n_name, *cpp) == 0) goto found; if (!nflag) (void) fclose(lfp); continue; } found: ... } This code segment was also present in the 4.3 BSD rdist. I have never understood the reason for the fclose(lfp) at that point. I believe that filev is from the command line. Even if one file in files does not match anything in filev a latter one might and lfp would be needed there. Anyway lfp is closed further down the code after the for loop so even if this questionable line is deleted lfp will still get closed. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu --- Cut Here --- *** client.c.ORIG Wed Sep 16 22:41:07 1992 --- client.c Thu Sep 17 13:53:01 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: client.c,v 6.24 1992/09/11 21:04:00 mcooper Exp mcooper $"; static char sccsid[] = "@(#)client.c"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: client.c,v 6.24 1992/09/11 21:04:00 mcooper Exp mcooper [mod WLS]$"; static char sccsid[] = "@(#)client.c"; *************** *** 67,73 **** /* * Return true if name is in the list. */ ! static int inlist(list, file) struct namelist *list; char *file; { --- 67,73 ---- /* * Return true if name is in the list. */ ! int inlist(list, file) struct namelist *list; char *file; { *** common.c.ORIG Wed Sep 16 13:32:10 1992 --- common.c Thu Sep 17 13:53:29 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: common.c,v 6.29 1992/09/11 21:09:45 mcooper Exp mcooper $"; static char sccsid[] = "@(#)common.c"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: common.c,v 6.29 1992/09/11 21:09:45 mcooper Exp mcooper [mod WLS]$"; static char sccsid[] = "@(#)common.c"; *************** *** 1019,1022 **** --- 1019,1104 ---- printf( "Version %s.%d - Protocol Version %d, Release %s, Patch level %d\n", DISTVERSION, PATCHLEVEL, VERSION, DISTVERSION, PATCHLEVEL); + } + + /* + * Execute a shell command to handle special cases. + * This is now common to both server and client + */ + void runcommand(cmd,fp) + char *cmd; + FILE *fp; + { + int fd[2], pid, i; + int status; + register char *cp, *s; + char sbuf[BUFSIZ]; + extern int userid, groupid; + + if (pipe(fd) < 0) { + error("pipe of %s failed: %s", cmd, SYSERR); + return; + } + + if ((pid = fork()) == 0) { + /* + * Return everything the shell commands print. + */ + (void) close(0); + (void) close(1); + (void) close(2); + (void) open(_PATH_DEVNULL, 0); + (void) dup(fd[1]); + (void) dup(fd[1]); + (void) close(fd[0]); + (void) close(fd[1]); + (void) execl(_PATH_BSHELL, "sh", "-c", cmd, 0); + _exit(127); + } + (void) close(fd[1]); + s = sbuf; + *s++ = C_LOGMSG; + while ((i = read(fd[0], buf, sizeof(buf))) > 0) { + cp = buf; + do { + *s++ = *cp++; + if (cp[-1] != '\n') { + if (s < &sbuf[sizeof(sbuf)-1]) + continue; + *s++ = '\n'; + } + /* + * Throw away blank lines. + */ + if (s == &sbuf[2]) { + s--; + continue; + } + if (isserver) + (void) write(rem, sbuf, s - sbuf); + else { + *s = '\0'; + log(fp, sbuf+1); + } + s = &sbuf[1]; + } while (--i); + } + if (s > &sbuf[1]) { + *s++ = '\n'; + if (isserver) + (void) write(rem, sbuf, s - sbuf); + else { + *s = '\0'; + log(fp, sbuf+1); + } + } + while ((i = wait(&status)) != pid && i != -1) + ; + if (i == -1) + status = -1; + (void) close(fd[0]); + if (status) + error("shell returned %d", status); + else if (isserver) + ack(); } *** defs.h.ORIG Tue Sep 15 13:04:29 1992 --- defs.h Thu Sep 17 13:53:47 1992 *************** *** 34,40 **** */ /* ! * $Id: defs.h,v 6.33 1992/09/15 17:04:10 mcooper Exp mcooper $ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ --- 34,40 ---- */ /* ! * $Id: defs.h,v 6.33 1992/09/15 17:04:10 mcooper Exp mcooper [mod WLS]$ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ *************** *** 306,311 **** --- 306,312 ---- * System function declarations */ char *malloc(); + char *realloc(); char *strchr(); char *strdup(); char *strrchr(); *************** *** 337,342 **** --- 338,344 ---- extern void note(); extern void printver(); extern void runcmdspecial(); + extern void runcommand(); extern void server(); extern void setproctitle(); extern void sighandler(); *** docmd.c.ORIG Mon Sep 14 15:52:27 1992 --- docmd.c Thu Sep 17 13:53:59 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.31 1992/09/14 19:52:06 mcooper Exp mcooper $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.31 1992/09/14 19:52:06 mcooper Exp mcooper [mod WLS]$"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 433,440 **** for (cpp = filev; *cpp; cpp++) if (strcmp(f->n_name, *cpp) == 0) goto found; - if (!nflag) - (void) fclose(lfp); continue; } found: --- 433,438 ---- *************** *** 502,509 **** return(0); } ! static void rcmptime(st) struct stat *st; { static void cmptime(); register DIR *d; --- 500,509 ---- return(0); } ! static void rcmptime(st, sbcmds, env) struct stat *st; + struct subcmd *sbcmds; + char **env; { static void cmptime(); register DIR *d; *************** *** 534,540 **** while (*ptarget++ = *cp++) ; ptarget--; ! cmptime(target); } (void) closedir((DIR *) d); ptarget = optarget; --- 534,540 ---- while (*ptarget++ = *cp++) ; ptarget--; ! cmptime(target, sbcmds, env); } (void) closedir((DIR *) d); ptarget = optarget; *************** *** 544,553 **** /* * Compare the mtime of file to the list of time stamps. */ ! static void cmptime(name) char *name; { struct stat stb; if (debug) (void) printf("cmptime(%s)\n", name); --- 544,557 ---- /* * Compare the mtime of file to the list of time stamps. */ ! static void cmptime(name, sbcmds, env) char *name; + struct subcmd *sbcmds; + char **env; { + struct subcmd *sc; struct stat stb; + int inlist(); if (debug) (void) printf("cmptime(%s)\n", name); *************** *** 580,586 **** break; case S_IFDIR: ! rcmptime(&stb); return; default: --- 584,590 ---- break; case S_IFDIR: ! rcmptime(&stb, sbcmds, env); return; default: *************** *** 588,595 **** return; } ! if (stb.st_mtime > lastmod) log(tfp, "new: %s", name); } /* --- 592,623 ---- return; } ! if (stb.st_mtime > lastmod) { log(tfp, "new: %s", name); + for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { + char buf[BUFSIZ]; + if (sc->sc_type != SPECIAL) + continue; + if (sc->sc_args != NULL && !inlist(sc->sc_args, name)) + continue; + (void ) sprintf(buf, "FILE=%s;%s", name, sc->sc_name); + log(tfp, "special \"%s\"\n", buf); + if (*env) { + *env = (char *) realloc(*env, strlen(*env) + + strlen(name) + 2); + if (*env == NULL) { + error("Out of memory (realloc())."); + return; + } + (void) strcat(*env, name); + (void) strcat(*env, ":"); + } + if (options & VERIFY) + continue; + + runcommand(buf, tfp); + } + } } /* *************** *** 607,613 **** struct stat stb; struct namelist *files = cmd->c_files; struct subcmd *sbcmds = cmd->c_cmds; ! char *stamp = cmd->c_name; if (debug) (void) printf("dodcolon()\n"); --- 635,641 ---- struct stat stb; struct namelist *files = cmd->c_files; struct subcmd *sbcmds = cmd->c_cmds; ! char *env, *stamp = cmd->c_name; if (debug) (void) printf("dodcolon()\n"); *************** *** 624,629 **** --- 652,670 ---- if (debug) (void) printf("%s: %d\n", stamp, stb.st_mtime); + env = NULL; + for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { + if (sc->sc_type == CMDSPECIAL) { + env = (char *)malloc(sizeof(E_FILES) + 3); + if (env == NULL) { + error("Out of memory."); + return; + } + (void) sprintf(env, "%s='", E_FILES); + break; + } + } + subcmds = sbcmds; lastmod = stb.st_mtime; if (nflag || (options & VERIFY)) *************** *** 630,640 **** tfp = NULL; else { if ((tfp = fopen(tempfile, "w")) == NULL) { ! error("%s: %s\n", stamp, SYSERR); return; } (void) gettimeofday(&tv[0], &tz); ! (void) setfiletime(stamp, &tv[0], &tv[0]); } for (f = files; f != NULL; f = f->n_next) { --- 671,682 ---- tfp = NULL; else { if ((tfp = fopen(tempfile, "w")) == NULL) { ! error("%s: %s\n", tempfile, SYSERR); return; } (void) gettimeofday(&tv[0], &tz); ! (void) setfiletime(stamp, (time_t)tv[0].tv_sec, ! (time_t)tv[0].tv_sec); } for (f = files; f != NULL; f = f->n_next) { *************** *** 646,660 **** } found: ptarget = NULL; ! cmptime(f->n_name); } if (tfp != NULL) (void) fclose(tfp); ! for (sc = sbcmds; sc != NULL; sc = sc->sc_next) if (sc->sc_type == NOTIFY) notify(tempfile, (char *)NULL, sc->sc_args, (time_t)lastmod); if (!nflag && !(options & VERIFY)) (void) unlink(tempfile); } --- 688,721 ---- } found: ptarget = NULL; ! cmptime(f->n_name, sbcmds, &env); } if (tfp != NULL) (void) fclose(tfp); ! for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { if (sc->sc_type == NOTIFY) notify(tempfile, (char *)NULL, sc->sc_args, (time_t)lastmod); + else if (sc->sc_type == CMDSPECIAL && env) { + char *p; + env = realloc(env, + strlen(env) + strlen(sc->sc_name) + 2); + if (env == NULL) { + error("Out of memory."); + return; + } + if (*(p = &env[strlen(env) - 1]) == ':') + *p = '\0'; + (void) strcat(env, "';"); + (void) strcat(env, sc->sc_name); + log(tfp, "cmdspecial \"%s\"\n", env); + if (!nflag && (options & VERIFY) == 0) + runcommand(env, tfp); + (void) free(env); + env = NULL; /* so cmdspecial is only called once */ + } + } if (!nflag && !(options & VERIFY)) (void) unlink(tempfile); } *** server.c.ORIG Fri Sep 11 22:04:51 1992 --- server.c Thu Sep 17 13:54:14 1992 *************** *** 32,38 **** */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 6.29 1992/09/12 02:02:36 mcooper Exp mcooper $"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; --- 32,38 ---- */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 6.29 1992/09/12 02:02:36 mcooper Exp mcooper [mod WLS]$"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; *************** *** 286,363 **** * We can't really set an alarm timeout here since we * have no idea how long the command should take. */ ! static void dospecial(cmd, env) char *cmd; - char *env; { ! int fd[2], pid, i; ! int status; ! register char *cp, *s; ! char sbuf[BUFSIZ], *ncmd = NULL; ! extern int userid, groupid; ! ! if (pipe(fd) < 0) { ! error("pipe of %s failed: %s", cmd, SYSERR); ! return; ! } ! if (env) { ! ncmd = malloc(strlen(cmd)+strlen(env)+2); ! (void) sprintf(ncmd, "%s;%s", env, cmd); ! cmd = ncmd; ! } ! if ((pid = fork()) == 0) { ! /* ! * Return everything the shell commands print. ! */ ! (void) close(0); ! (void) close(1); ! (void) close(2); ! (void) open(_PATH_DEVNULL, 0); ! (void) dup(fd[1]); ! (void) dup(fd[1]); ! (void) close(fd[0]); ! (void) close(fd[1]); ! (void) execl(_PATH_BSHELL, "sh", "-c", cmd, 0); ! _exit(127); ! } ! (void) close(fd[1]); ! s = sbuf; ! *s++ = C_LOGMSG; ! while ((i = read(fd[0], buf, sizeof(buf))) > 0) { ! cp = buf; ! do { ! *s++ = *cp++; ! if (cp[-1] != '\n') { ! if (s < &sbuf[sizeof(sbuf)-1]) ! continue; ! *s++ = '\n'; ! } ! /* ! * Throw away blank lines. ! */ ! if (s == &sbuf[2]) { ! s--; ! continue; ! } ! (void) write(rem, sbuf, s - sbuf); ! s = &sbuf[1]; ! } while (--i); ! } ! if (s > &sbuf[1]) { ! *s++ = '\n'; ! (void) write(rem, sbuf, s - sbuf); ! } ! while ((i = wait(&status)) != pid && i != -1) ! ; ! if (i == -1) ! status = -1; ! (void) close(fd[0]); ! if (ncmd) ! (void) free(ncmd); ! if (status) ! error("shell returned %d", status); ! else ! ack(); } /* --- 286,295 ---- * We can't really set an alarm timeout here since we * have no idea how long the command should take. */ ! static void dospecial(cmd) char *cmd; { ! runcommand(cmd, (FILE *)NULL); } /* *************** *** 371,377 **** static void docmdspecial() { register char *cp; ! char *env = NULL; int n; /* We're ready */ --- 303,309 ---- static void docmdspecial() { register char *cp; ! char *cmd, *env = NULL; int n; /* We're ready */ *************** *** 408,414 **** break; case RC_COMMAND: ! dospecial(cp, env); if (env) (void) free(env); return; --- 340,359 ---- break; case RC_COMMAND: ! if (env) { ! env = (char *)realloc(env, strlen(env) + ! strlen(cp) + 2); ! if (env == NULL) { ! error("Out of memory."); ! return; ! } ! (void) strcat(env, ";"); ! (void) strcat(env, cp); ! cmd = env; ! } else ! cmd = cp; ! ! dospecial(cmd); if (env) (void) free(env); return; ---- Cut Here --- From mcooper@ucs.usc.edu Thu Sep 17 13:17:02 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3++) id AA09208; Thu, 17 Sep 92 13:17:02 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.3) id AA05100; Thu, 17 Sep 92 13:16:57 PDT Sender: "Michael A. Cooper" Date: Thu, 17 Sep 92 13:16:53 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: wls@astro.UMD.EDU Cc: rdist@usc.edu Subject: Re: special & cmdspecial in :: construction In-Reply-To: Your message of Thu, 17 Sep 1992 14:05:12 -0400 Message-Id: Bill, Your changes look good. I've installed them. Thanks! mike From wls@astro.UMD.EDU Mon Sep 21 08:41:13 1992 Received: from astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA28023; Mon, 21 Sep 92 08:41:13 PDT Return-Path: Received: by astro.astro.umd.edu (5.65c/5.61sWLS) id AA07513; Mon, 21 Sep 1992 11:41:08 -0400 Date: Mon, 21 Sep 1992 11:41:08 -0400 From: wls@astro.UMD.EDU Message-Id: <199209211541.AA07513@astro.astro.umd.edu> To: rdist@usc.edu. Subject: all is not well I recently installed rdist6.0beta5 with the patches I posted last week. Here is a small piece of the log of one of the sessions. updating host corona updating host cosmos updating host capricorn updating host ceres cosmos: LOCAL ERROR: cannot open capricorn: LOCAL ERROR: cannot open updating host fornax updating host eastman updating of corona finished updating host halley fornax: LOCAL ERROR: cannot open updating host herschel eastman: LOCAL ERROR: cannot open updating host hubble updating of ceres finished updating host hyades updating of hubble finished updating of herschel finished updating host jupiter updating host icarus jupiter: LOCAL ERROR: cannot open updating host leo leo: LOCAL ERROR: cannot open updating host lmc lmc: LOCAL ERROR: cannot open updating host lynx lynx: LOCAL ERROR: cannot open updating host lyra lyra: LOCAL ERROR: cannot open updating host neptune neptune: LOCAL ERROR: cannot open updating host pleiades pleiades: LOCAL ERROR: cannot open updating host saturn updating of halley finished updating host sextans saturn: LOCAL ERROR: cannot open updating host smc updating of hyades finished updating host sol updating of icarus finished updating host titan updating of smc finished updating host tucana updating of sextans finished updating host vela titan: LOCAL ERROR: cannot open updating of sol finished updating of vela finished updating of tucana finished Note all of the "LOCAL ERROR: cannot open" messages. I don't think that my patches are at fault because the feature they provide (use of "special" command in :: construction) was not used in this particular session. The hosts affected by the LOCAL ERROR are different every time so it seems to be some sort of race condition. I know that what I have included above is not enough for someone else to say what the problem is unless they have seen this problem themselves. This is just a preliminary note about a problem which I have started to work on. The Distfile is a bit large to include and right now I do not know what in it is important for this problem. rdist itself was started with no options. Tonight I will run this with the -F option and see if that makes a difference. If it does go away with the -F option then it will be very devilish to debug. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Mon Sep 21 09:06:22 1992 Received: from astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA29788; Mon, 21 Sep 92 09:06:22 PDT Return-Path: Received: by astro.astro.umd.edu (5.65c/5.61sWLS) id AA08337; Mon, 21 Sep 1992 12:06:21 -0400 Date: Mon, 21 Sep 1992 12:06:21 -0400 From: wls@astro.UMD.EDU Message-Id: <199209211606.AA08337@astro.astro.umd.edu> To: rdist@usc.edu Subject: Re: all is not well Here is more information: Also I had installed the patches recently suggested by Mike Cooper involving the addition of mktemp() calls to rdist.c and docmd.c. The error message must be coming from the piece in docmd.c function doarrow(): if ((lfp = fopen(tempfile, "w")) == NULL) { fatal("cannot open %s\n", tempfile); exit(1); } On looking at the "LOCAL ERROR: cannot open " messages in the log they do seem to have a space at the end of them before the newline. Therefore somehow tempfile is getting set to contain a zero length string. The man page on mktemp (SunOS 4.1.2) says: mktemp() assigns the null string to template when it cannot create a unique name. Somehow, it seems that this must be occurring. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Mon Sep 21 09:51:04 1992 Received: from astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA03240; Mon, 21 Sep 92 09:51:04 PDT Return-Path: Received: by astro.astro.umd.edu (5.65c/5.61sWLS) id AA09173; Mon, 21 Sep 1992 12:50:59 -0400 Date: Mon, 21 Sep 1992 12:50:59 -0400 From: wls@astro.UMD.EDU Message-Id: <199209211650.AA09173@astro.astro.umd.edu> To: rdist@usc.edu Subject: Fix for "LOCAL ERROR: cannot open problem" Here is a patch. The tempfile array in the child process needed to be reinitialized before calling mktemp(tempfile) (file docmd.c function docmdhost()). While I'm at it I think that the new mktemp(tempfile) in main() (rdist.c) makes the subsequent mktemp(tempfile) in docmdargs() (also rdist.c) redundant. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu *** rdist.c.SAV Thu Sep 17 14:22:53 1992 --- rdist.c Mon Sep 21 12:30:09 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 6.38 1992/08/31 22:11:43 mcooper Exp mcooper $"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 6.38 1992/08/31 22:11:43 mcooper Exp mcooper [WLS mod]$"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; *************** *** 356,363 **** hosts = expand(&tnl, E_ALL); if (nerrs) exit(1); - (void) mktemp(tempfile); - if (dest == NULL || *dest == '\0') cmds = NULL; else { --- 356,361 ---- *** docmd.c.SAV Thu Sep 17 14:22:54 1992 --- docmd.c Mon Sep 21 12:31:27 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.31 1992/09/14 19:52:06 mcooper Exp mcooper [mod WLS]$"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.31 1992/09/14 19:52:06 mcooper Exp mcooper [mod WLS2]$"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 834,839 **** --- 834,840 ---- setproctitle("update %s", currenthost); #endif /* SETARGS */ } + (void) sprintf(tempfile, "%s/%s", _PATH_TMP, _RDIST_TMP); (void) mktemp(tempfile); switch (cmd->c_type) { From romig@cis.ohio-state.edu Mon Sep 21 11:13:14 1992 Return-Path: Received: from brachiosaur.cis.ohio-state.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA08927; Mon, 21 Sep 92 11:13:14 PDT Received: by brachiosaur.cis.ohio-state.edu (5.61-kk/5.911008) id AA06173; Mon, 21 Sep 92 14:13:10 -0400 Date: Mon, 21 Sep 92 14:13:10 -0400 From: Steve Romig Message-Id: <9209211813.AA06173@brachiosaur.cis.ohio-state.edu> To: rdist@usc.edu Subject: Message filter for rdist We wrote a simple message filter for rdist that others might be interested in. It collects messages that are similar for groups of hosts and bundles them together, so that instead of the usual messages you get a more organized and compact report: ------------------------------------------------------------------------------ user: frank directories: /export/local/bin/X11 hosts: monster weather dinosaur spice tribe fish vegetable seuss nervous tree oz pasta spare2 unit ship bird shell solar spyglass spyglass chmod: /export/local/bin/X11 from 755 to 2755 nervous chmod: /export/local/bin/X11 from 777 to 2755 spice.cis.ohio-state.edu unit.cis.ohio-state.edu weather.cis.ohio-state.edu Connection timed out bird dinosaur fish flower fruit icecream mammal monster music nervous news oz pasta reptile seuss shell ship solar spare2 sport spyglass tree tribe vegetable updating: /export/local/bin/X11/xmessage updating: /export/local/bin/X11/xshutdown ------------------------------------------------------------------------------ Source for the script (we call it compact-rdist-output) can be found in ftp.cis.ohio-state.edu:/pub/misc/compact-rdist-output. Use it as in "rdist | compact-rdist-output". Comments, suggestions, bug reports and especially bug fixes would all be appreciated... --- Steve From rouilj@ra.cs.umb.edu Thu Sep 24 15:40:35 1992 Return-Path: Received: from ra.cs.umb.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA05120; Thu, 24 Sep 92 13:56:38 PDT Received: by ra.cs.umb.edu id AA09849 (5.65c/IDA-1.4.4 for rdist@usc.edu); Thu, 24 Sep 1992 16:56:35 -0400 From: "John P. Rouillard" Message-Id: <199209242056.AA09849@ra.cs.umb.edu> Subject: Wierd problem in 6.0B3 under Ultrix 4.2 To: rdist@usc.edu Date: Thu, 24 Sep 92 16:56:35 EDT X-Mailer: ELM [version 2.3 PL11] Hello: When I invoke rdist as: rdist -m dlws6.bc.edu binaries automount bind foo it seems that I get a bunch of rdist: don't know how to rdist where target is every label on the command line EXCEPT the first. so the output from the above command line would be: rdist: don't know how to rdist automount. rdist: don't know how to rdist bind. rdist: don't know how to rdist foo. I usually run rdist with 30 or so targets, so this gets to be a problem rather quickly. I noticed that the Changelog file said that a problem like this was fixed around 6.0 alpha 3. Does anybody have any ideas before I start running rdist under gdb? Just for completeness I am running version 6.0 beta 3 of rdist from USC under version 4.2 Ultrix. Thanks. -- John -- From mcooper@ucs.usc.edu Thu Sep 24 16:46:16 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA14757; Thu, 24 Sep 92 16:46:16 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.3) id AA19638; Thu, 24 Sep 92 16:46:14 PDT Sender: "Michael A. Cooper" Date: Thu, 24 Sep 92 16:46:12 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "John P. Rouillard" Cc: rdist@usc.edu Subject: Re: Wierd problem in 6.0B3 under Ultrix 4.2 In-Reply-To: Your message of Thu, 24 Sep 92 16:56:35 EDT Message-Id: That problem is fixed in 6.0beta5 available on usc.edu for ftp as /pub/rdist/rdist.tar.Z. However, there is a known problem with "notify" not working which is fixed in the next release. There's also a patch in /pub/rdist/mail.archive. mike From rouilj@ra.cs.umb.edu Fri Sep 25 13:34:47 1992 Return-Path: Received: from ra.cs.umb.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA13870; Fri, 25 Sep 92 13:34:47 PDT Received: by ra.cs.umb.edu id AA06136 (5.65c/IDA-1.4.4 for rdist@usc.edu); Fri, 25 Sep 1992 13:35:53 -0400 From: "John P. Rouillard" Message-Id: <199209251735.AA06136@ra.cs.umb.edu> Subject: setting owner, and permissions. To: rdist@usc.edu Date: Fri, 25 Sep 92 13:35:53 EDT X-Mailer: ELM [version 2.3 PL11] Hi: In my rdist area I have a file -rwxr-xr-x 1 root system 73728 Jun 22 19:03 /config/binaries/lwhod However the corresponding file on the workstation has the following permissions: -rwxr-xr-x 1 rouilj system 73728 Jun 22 19:03 /usr/etc/lwhod from an earlier Rdist when the owner was incorrectly set. I was under the impression that this rdist would check the permissions and ownership and fix them if necessary. It is still true that I have to touch the master copy of the file to force an update of the entire file in order to fix the permissions. This is rdist 6.0 beta 5 under Ultrix 4.2. Thanks. -- John -- From mcooper@ucs.usc.edu Fri Sep 25 13:54:19 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA15010; Fri, 25 Sep 92 13:54:19 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.3) id AA20971; Fri, 25 Sep 92 13:54:11 PDT Sender: "Michael A. Cooper" Date: Fri, 25 Sep 92 13:54:08 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "John P. Rouillard" Cc: rdist@usc.edu Subject: Re: setting owner, and permissions. In-Reply-To: Your message of Fri, 25 Sep 92 13:35:53 EDT Message-Id: That feature "broke" in 6.0beta.5. It's fixed in the next release which I hope to get out in a week or two. mike From scott@udel.edu Fri Oct 2 19:55:51 1992 Return-Path: Received: from louie.udel.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.1) id AA04282; Fri, 2 Oct 92 19:55:51 PDT Received: from localhost.udel.edu by louie.udel.edu id aa29716; 2 Oct 92 22:51 EDT To: rdist@usc.edu Subject: link bug? Date: Fri, 02 Oct 92 22:51:16 -0400 From: Doke Message-Id: <9210022251.aa29716@louie.udel.edu> I'm having some trouble with rdisting hard linked files to alternate destinations. The first of a pair of hard links gets installed correctly. The second is created (attemped) as a link to a (usually non-existant) file with the name that the file has on the source system. Example: snow-white.ee.udel.edu, a sun4/330, is our main NFS server. A number of sun4c clients mount it's /usr. Too many sun3 clients mount /usr/sun3 from it as their /usr. dip.ee.udel.edu is a sun3/280 NFS server for a subnet. It also has sun3 and sun4c clients, mounting /usr and /usr/sun4c respectively. (There actually are some good reasons for this.) I need to rdist parts of snow-white:/usr to dip:/usr/sun4c, and snow-white:/usr/sun3 to dip:/usr. rdist correctly copies snow-white:/usr/bin/chfn to dip:/usr/sun4c/bin/chfn. However, instead of hardlinking dip:/usr/sun4c/bin/chsh to the newly installed chfn, it links it to /usr/bin/chfn, the pathname on the _original_ system. sun3 binaries run very badly on sparcs. In a simpler setup where the original pathname doesn't exist on the destination system, an error message comes back: "REMOTE ERROR: cannot link to : No such file or directory". Below is a diff (to 6.0beta.5) that tries to address this problem. It seems to work, but I'm sure it breaks something else. It has only been tested on suns. Opinions? Thanks, Doke *** orig/client.c Fri Sep 11 17:05:17 1992 --- src/client.c Fri Oct 2 22:14:00 1992 *************** *** 60,66 **** --- 60,68 ---- struct linkbuf *ihead = NULL; /* list of files with more than one link */ char buf[BUFSIZ]; /* general purpose buffer */ char target[BUFSIZ]; /* target/source directory name */ + char destbuf[BUFSIZ]; /* destination directory name */ char *ptarget; /* pointer to end of target name */ + char *pdestbuf; /* pointer to end of destbuf name */ char *Tdest; /* pointer to last T dest*/ extern FILE *lfp; /* log file for mailing changes */ *************** *** 180,186 **** lp->inum = statp->st_ino; lp->devnum = statp->st_dev; lp->count = statp->st_nlink - 1; ! (void) strcpy(lp->pathname, target); if (Tdest) (void) strcpy(lp->target, Tdest); else --- 182,188 ---- lp->inum = statp->st_ino; lp->devnum = statp->st_dev; lp->count = statp->st_nlink - 1; ! (void) strcpy(lp->pathname, destbuf); if (Tdest) (void) strcpy(lp->target, Tdest); else *************** *** 372,379 **** { DIRENTRY *dp; DIR *d; ! char *optarget, *cp; ! int len; static void sendit(); /* --- 374,381 ---- { DIRENTRY *dp; DIR *d; ! char *optarget, *opdestbuf, *cp; ! int len, dlen; static void sendit(); /* *************** *** 399,408 **** } optarget = ptarget; len = ptarget - target; while (dp = readdir(d)) { ! if (!strcmp(dp->d_name, ".") || ! !strcmp(dp->d_name, "..")) continue; if (len + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { error("%s/%s: Name too long", target, --- 401,413 ---- } optarget = ptarget; + opdestbuf = pdestbuf; len = ptarget - target; + dlen = pdestbuf - destbuf; while (dp = readdir(d)) { ! if ( *dp->d_name == '.' && ! ( !strcmp(dp->d_name, ".") || ! !strcmp(dp->d_name, "..") ) ) continue; if (len + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { error("%s/%s: Name too long", target, *************** *** 409,420 **** dp->d_name); continue; } ptarget = optarget; *ptarget++ = '/'; cp = dp->d_name; ! while (*ptarget++ = *cp++) ; ptarget--; sendit(dp->d_name, opts); } (void) closedir(d); --- 414,433 ---- dp->d_name); continue; } + if (dlen + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { + error("%s/%s: Name too long", destbuf, + dp->d_name); + continue; + } ptarget = optarget; + pdestbuf = opdestbuf; *ptarget++ = '/'; + *pdestbuf++ = '/'; cp = dp->d_name; ! while (*pdestbuf++ = *ptarget++ = *cp++) ; ptarget--; + pdestbuf--; sendit(dp->d_name, opts); } (void) closedir(d); *************** *** 423,429 **** --- 436,444 ---- (void) response(); ptarget = optarget; + pdestbuf = opdestbuf; *ptarget = CNULL; + *pdestbuf = CNULL; } /* *************** *** 867,875 **** return; } ! rname = exptilde(target, src); if (rname == NULL) return; ptarget = target; while (*ptarget) ptarget++; --- 882,899 ---- return; } ! if (opts & WHOLE) ! rname = exptilde(destbuf, src ); ! else ! rname = exptilde(destbuf, dest ); if (rname == NULL) return; + for( pdestbuf = destbuf; *pdestbuf; pdestbuf++ ) + ; + + ptarget = exptilde(target, src); + if (ptarget == NULL) + return; ptarget = target; while (*ptarget) ptarget++; *************** *** 883,900 **** rname++; destdir = 1; } else { ! rname = strrchr(target, '/'); ! /* Check if no '/' or target ends in '/' */ if (rname == NULL || rname+1 == NULL || *(rname+1) == CNULL) ! rname = target; else rname++; } if (debug) ! (void) printf("target = %s, rname = %s\n", target, rname); /* * Pass the destination file/directory name to remote. --- 907,925 ---- rname++; destdir = 1; } else { ! rname = strrchr(destbuf, '/'); ! /* Check if no '/' or destbuf ends in '/' */ if (rname == NULL || rname+1 == NULL || *(rname+1) == CNULL) ! rname = destbuf; else rname++; } if (debug) ! (void) printf("target = %s, destbuf = %s, rname = %s\n", ! target, destbuf, rname); /* * Pass the destination file/directory name to remote. From mcooper@ucs.usc.edu Tue Oct 13 17:26:29 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA15064; Tue, 13 Oct 92 17:26:29 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA06406; Tue, 13 Oct 92 16:43:09 PDT Sender: "Michael A. Cooper" Date: Tue, 13 Oct 92 16:43:07 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Rdist 6.0beta.6 now available Message-Id: Patchlevel 6 is now available for ftp on usc.edu. There have been extensive changes in this version which have taken some time to implement. I have implemented my promised overhaul to the message handling subsystem. It's been totally revamped. A number of subtle bugs were uncovered during this process. Undoubtable new subtle bugs have been introduced. A number of people have reported bugs, almost all of which I believe are fixed, but extensive testing has not been done. A few of these bugs involved some problems with not fully checking file/directory ownership and modes. To fix these problems I had to make a CHANGE IN THE PROTOCOL. Rdist 6.0beta.6 clients (rdist) will talk fine to both old and new rdistd 6.0beta server's. However, the 6.0beta.6 server (rdistd) will NOT talk to pre 6.0beta.6 clients (rdist). I decided that since this is a beta release still, it was not worth the effort of adding backward compatbility in the server for older 6.0beta clients. This version of rdist also makes use of select() for reading the output of it's children. You should still be able to get the old behavior if you don't have select(), but I haven't tested this. Steve Romig has contributed his "compact" rdist filter (included as rdistcfilter). This is really useful for greatly reducing the output from rdist. mike Tue Oct 13 15:07:56 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.0beta.6. * Fix possible stack overflow problem in expand code. Mon Oct 12 19:41:24 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix long term problem with hardlink installations. ( Andreas Luik) * Slight performance improvement in reading directories. * Add better checking/setting of directory ownership. * Add another check to see if remote owner.group match local owner.group. Fri Oct 9 13:01:23 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * All OS dependent filesystem routines moved from filesys.c to new getmount.c. * Add support for BSD386. (Ken Dahl) * Move OS name definetions from config.h to new config-os.h. * Change configdata.h to config-data.h and create config-os.h. * Fix chkparent() to actually make directories when needed. Wed Oct 7 11:20:23 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Use standard system and predefined values for open() and pipe(). * Children now exit with status "nerrs". * Only log debugmsg() about exit status of child for legit children. * Massive overhual of internal message handling system. All messages now pass through the message() function. There are different message facilities are configured to handle the different message types. The format of messages has also been made more consistent. Thu Sep 24 11:11:19 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Use new x*alloc() functions that do error checking. * Major changes to use select() to read input from children. * Major code cleanup of children related functions. * Add Steve Romig's "compact-rdist-output" perl filter to the distribution as "rdistcfilter.pl". Also renamed rdistfilter.pl to be rdistvfilter.pl. Thu Sep 17 13:13:35 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Remove extraneous fclose(lfp) in doarrow(). (Bill Sebok) * Fix botch with setfiletime() which set bogus file times. (Bill Sebok) * Make :: work for special and cmdspecial. (Bill Sebok) Wed Sep 16 16:49:13 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem with tempfile (/tmp/rdistXXXXXX) being removed when it shouldn't. From neal@ctd.comsat.com Wed Oct 14 06:24:29 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA18522; Wed, 14 Oct 92 06:24:29 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mf8i5-0003TdC; Wed, 14 Oct 92 09:24 EDT Message-Id: Date: Wed, 14 Oct 92 09:24 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: Symantics of log options? The new logging facility looks great! My only problem now is, is there any doc explaining what different log levels mean? For example, I want to know about any file updates, and any signs of trouble, but not normal operation. I am starting rdist with: -l syslog=change,notice,nerror,ferror,warning I guess info is for stuff that is perfectly normal? Is this the correct usage? Or are these a hierarchy of levels so that I need only select say, notice, to enable all higher levels? BTW, how do you use the 'file' facility? Where do you specify the file name? Thanks! You all look like happy campers to me. Happy campers you are, happy campers you have been, and, as far as I am concerned, happy campers you will always be. -- Vice President Dan Quayle, to the American Samoans, whose capital Quayle pronounces 'Pogo Pogo' From neal@ctd.comsat.com Wed Oct 14 08:07:39 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA21831; Wed, 14 Oct 92 08:07:39 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfAK1-0003TdC; Wed, 14 Oct 92 11:07 EDT Message-Id: Date: Wed, 14 Oct 92 11:07 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: DANGER - rdist-6.0beta.6 AMNESIA I don't know what's causing the problem, but I just installed rdist-6.0beta.6 on hpux-8.07 hp9000/720. I'm finding that rdist is not updating all hosts. It is forgetting about a fair number of them. The ones forgotten are always the same, but there is no apparent pattern. Using rdist -D shows there was never any attempt to update them. You smile discreetly. Look like you're enjoying yourself, like you're ready to get down to serious business. You've got to be careful what you say. -- Vice President Dan Quayle, explaining to Latin American leaders how to handle a photo op. From neal@ctd.comsat.com Wed Oct 14 08:15:22 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA22222; Wed, 14 Oct 92 08:15:22 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfART-0003TdC; Wed, 14 Oct 92 11:15 EDT Message-Id: Date: Wed, 14 Oct 92 11:15 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: DANGER - rdist-6.0beta.6 AMNESIA In-Reply-To: References: >>>>> On Wed, 14 Oct 92 11:07 EDT, neal@ctd.comsat.com (Neal Becker) said: Neal> I don't know what's causing the problem, but I just installed Neal> rdist-6.0beta.6 on hpux-8.07 hp9000/720. I'm finding that rdist is Neal> not updating all hosts. It is forgetting about a fair number of them. Neal> The ones forgotten are always the same, but there is no apparent Neal> pattern. Neal> Using rdist -D shows there was never any attempt to update them. Well, now, isn't this interesting? When I use -F then missing hosts are updated, but without -F they're not. Hmm... A kitchen in every pot. I mean, a pot in every -- I mean, a chicken in every... -- George Bush, 1988. From neal@ctd.comsat.com Wed Oct 14 08:30:19 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA22649; Wed, 14 Oct 92 08:30:19 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfAfx-0003TdC; Wed, 14 Oct 92 11:30 EDT Message-Id: Date: Wed, 14 Oct 92 11:30 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: DANGER - rdist-6.0beta.6 AMNESIA In-Reply-To: References: In child.c line 321 change to: debugmsg(DM_MISC, "waitup() Call select(%d)\n", activechildren); Since Bush became president... Mean annual income of the wealthiest 5% of US families: +$7,286 (up 5%) Mean annual income of the poorest one-fifth: -$54 (down .5%) From neal@ctd.comsat.com Wed Oct 14 09:11:45 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA24295; Wed, 14 Oct 92 09:11:45 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfAtS-0003TdC; Wed, 14 Oct 92 11:44 EDT Message-Id: Date: Wed, 14 Oct 92 11:44 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: DANGER - rdist-6.0beta.6 AMNESIA In-Reply-To: References: Here's an excerpt from rdist -D -m daffy. I think the problem may relate to the errno = 2? ------------------------------------------------------ neal: spawn() Forked child 11806 for host daffy active = 1 neal: prev assigned: daffy neal: prev assigned: daffy neal: Waiting for 1 children to finish. neal: waitup() start neal: waitup() select on 3 (daffy) neal: waitup() Call select(1) neal: waitup() select returned 1 activechildren = 1 neal: [readchild(daffy, 11806, 3) start] neal: [readchild(daffy, 11806, 3) got 182 bytes] daffy: doarrow(4001cbe8, daffy, 4001c758) start daffy: makeconn(daffy) daffy: updating host daffy daffy: port = 514 local user = root remote user = root daffy: Command = 'rdistd -S' neal: [readchild(daffy, 11806, 3) write done] neal: readchild(daffy, 11806, 3) done: amt = 0 errno = 2 neal: readchild(daffy, 11806, 3) at EOF neal: removechild(daffy, 11806, 3) start neal: removechild() end neal: waitup() calling reap neal: reap() called neal: waitproc() nonblocking, active children = 0... neal: waitproc() done (activechildren = 0) neal: reap() pid = 0 status = 0 activechildren=0 neal: reap() done I can't say I identify with any specific educational goal. -- George Bush, 1988. From mcooper@ucs.usc.edu Wed Oct 14 10:31:43 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA28032; Wed, 14 Oct 92 10:31:43 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA07040; Wed, 14 Oct 92 10:31:28 PDT Sender: "Michael A. Cooper" Date: Wed, 14 Oct 92 10:31:28 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: Symantics of log options? In-Reply-To: Your message of Wed, 14 Oct 92 09:24 EDT Message-Id: Yes, documentation is very incomplete on logging right now. I'll update the man page for the next release. For now, look in message.c for specific details. BTW, the "file" logging looks like: -l file=/tmp/rdist.log=change,info The levels are not a hierarchy like syslog. Each level stands on it's own. mike From neal@ctd.comsat.com Thu Oct 15 07:58:54 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA18992; Thu, 15 Oct 92 07:58:54 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfWf2-0003TdC; Thu, 15 Oct 92 10:58 EDT Message-Id: Date: Thu, 15 Oct 92 10:58 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: minor bug with patch Found a mistake in list handling in child.c, there is no evidence that this is causing any serious problem though. ----------------------------------------- rdiff -r1.1 child.c 120c120 < register CHILD *pc; --- > register CHILD *pc, *prev; 132,133c132,133 < for (found = FALSE, pc = childlist; < !found && pc && pc->c_next; pc = pc->c_next) --- > for (found = FALSE, pc = childlist, prev = NULL; > !found && pc ; prev = pc, pc = pc->c_next) 143c143 < pc->c_next = copychild(child); --- > prev->c_next = copychild(child); I bet I prepared a couple of hundred thousand pages of memoranda that went ... to the Vice President's office. -- Oliver North. From root@ctd.comsat.com Thu Oct 15 08:27:30 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA19953; Thu, 15 Oct 92 08:27:30 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfX6j-0003TdC; Thu, 15 Oct 92 11:27 EDT Message-Id: Date: Thu, 15 Oct 92 11:27 EDT From: root@ctd.comsat.com To: rdist@usc.edu test From neal@ctd.comsat.com Thu Oct 15 08:40:01 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA20757; Thu, 15 Oct 92 08:40:01 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfXIt-0003TdC; Thu, 15 Oct 92 11:39 EDT Message-Id: Date: Thu, 15 Oct 92 11:39 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: More on rdist6.0beta6 problems As I reported previously, rdist on hpux is dying when trying to update files. The problem does *not* occur if I use -F. Using -L option to log to a file, it appears that rdist dies as soon as it tries to send a file. Here is an excerpt of the log created at "daffy" while trying to update "daffy". rdist -l file=/tmp/junk=debug -L file=/tmp/junk=debug -f /local/rdist/distfile -m daffy -F daffy: <<< Cmd = t (\164) Msg = "0 /etc/passwd" daffy: >>> Cmd =  (\005) Msg = "" daffy: <<< Cmd = Q (\121) Msg = "passwd" daffy: >>> Cmd = Y (\131) Msg = "3515 719160957 444 root sys" daffy: <<< Cmd = R (\122) Msg = "0 444 3515 719162454 719162723 root sys passwd" daffy: recvit: opts = 0 mode = 444 size = 3515 mtime = 719162454 daffy: recvit: owner = 'root' group = 'sys' file = 'passwd' catname = 0 isdir = 0 daffy: >>> Cmd =  (\005) Msg = "" daffy: response() start daffy: <<< Cmd =  (\005) Msg = "" daffy: recieved ACK daffy: >>> Cmd =  (\005) Msg = "" daffy: <<< Cmd = t (\164) Msg = "0 /etc/group" Without -F: daffy: <<< Cmd = t (\164) Msg = "0 /etc/passwd" daffy: >>> Cmd =  (\005) Msg = "" daffy: <<< Cmd = Q (\121) Msg = "passwd" daffy: >>> Cmd = Y (\131) Msg = "3515 719162454 444 root sys" [ END OF FILE ] From mcooper@ucs.usc.edu Thu Oct 15 10:35:39 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA26082; Thu, 15 Oct 92 10:35:39 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA10575; Thu, 15 Oct 92 10:35:33 PDT Sender: "Michael A. Cooper" Date: Thu, 15 Oct 92 10:35:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: More on rdist6.0beta6 problems In-Reply-To: Your message of Thu, 15 Oct 92 11:39 EDT Message-Id: Are you sure the remote host is running the current rdistd? If not, it won't like the logging options that rdist passes it. If this isn't the problem, then it's probably HPUX specific. mike From mcooper@ucs.usc.edu Thu Oct 15 14:31:29 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA07845; Thu, 15 Oct 92 14:31:29 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA11575; Thu, 15 Oct 92 14:31:22 PDT Sender: "Michael A. Cooper" Date: Thu, 15 Oct 92 14:31:21 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: minor bug with patch In-Reply-To: Your message of Thu, 15 Oct 92 10:58 EDT Message-Id: > Found a mistake in list handling in child.c, there is no evidence that > this is causing any serious problem though. > > ----------------------------------------- > rdiff -r1.1 child.c > 120c120 > < register CHILD *pc; > --- > > register CHILD *pc, *prev; > 132,133c132,133 > < for (found = FALSE, pc = childlist; > < !found && pc && pc->c_next; pc = pc->c_next) > --- > > for (found = FALSE, pc = childlist, prev = NULL; > > !found && pc ; prev = pc, pc = pc->c_next) > 143c143 > < pc->c_next = copychild(child); > --- > > prev->c_next = copychild(child); > > > > I bet I prepared a couple of hundred thousand pages of memoranda that > went ... to the Vice President's office. > -- Oliver North. > I believe the only mistake is that it's possible to NULL deref "pc" if (!found). mike From neal@ctd.comsat.com Fri Oct 16 07:39:41 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA17640; Fri, 16 Oct 92 07:39:41 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfsq1-0003TdC; Fri, 16 Oct 92 10:39 EDT Message-Id: Date: Fri, 16 Oct 92 10:39 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist@usc.edu Subject: rdist6.0beta6/hpux FIXED! In child.c several things are fixed. Now it appears to be working OK for me. I *don't* think this is HPUX-specific. I think it is a timing problem! 1) trivial list-handling mistake 2) Only call removechild() from reap(). 3) Don't call reap(). Let SIGCHLD call reap(). This is the important change. We only remove a child process when SIGCHILD tells us a child has exited. 4) Trivial %d missing for debugmsg. You may want to remove the comment before waitup() which says "Wait up for children to exit". if HAVE_SELECT, it's really waiting for data to be available for reading. People were out there looting their asses off... When they saw us, they shouted, `Viva Bush!' -- A US soldier present at the invasion of Panama. ----------------------------------------------- gdiff -c rdist-6.0beta.6.orig/child.c rdist-6.0beta.6/child.c *** rdist-6.0beta.6.orig/child.c Fri Oct 9 19:18:09 1992 --- rdist-6.0beta.6/child.c Fri Oct 16 10:22:02 1992 *************** *** 117,123 **** static void addchild(child) CHILD *child; { ! register CHILD *pc; int found; debugmsg(DM_CALL, "addchild() start\n"); --- 117,123 ---- static void addchild(child) CHILD *child; { ! register CHILD *pc, *prev; int found; debugmsg(DM_CALL, "addchild() start\n"); *************** *** 129,136 **** * Try to re-use empty slots in the child list. * If none are found, then add to end of list. */ ! for (found = FALSE, pc = childlist; ! !found && pc && pc->c_next; pc = pc->c_next) if (pc->c_name == NULL) { /* Re-use old slot */ pc->c_name = strdup(child->c_name); --- 129,136 ---- * Try to re-use empty slots in the child list. * If none are found, then add to end of list. */ ! for (found = FALSE, pc = childlist, prev = NULL; ! !found && pc ; prev = pc, pc = pc->c_next) if (pc->c_name == NULL) { /* Re-use old slot */ pc->c_name = strdup(child->c_name); *************** *** 140,146 **** } if (!found) /* Create a new child */ ! pc->c_next = copychild(child); } ++activechildren; --- 140,146 ---- } if (!found) /* Create a new child */ ! prev->c_next = copychild(child); } ++activechildren; *************** *** 194,200 **** if (amt == 0) { debugmsg(DM_MISC, "readchild(%s, %d, %d) at EOF\n", child->c_name, child->c_pid, child->c_readfd); - removechild(child); } } --- 194,199 ---- *************** *** 318,324 **** /* * Actually call select() */ ! debugmsg(DM_MISC, "waitup() Call select()\n", activechildren); count = select(FD_SETSIZE, &rchildfds, (fd_set *) NULL, (fd_set *) NULL, (struct timeval *) NULL); --- 317,323 ---- /* * Actually call select() */ ! debugmsg(DM_MISC, "waitup() Call select(%d)\n", activechildren); count = select(FD_SETSIZE, &rchildfds, (fd_set *) NULL, (fd_set *) NULL, (struct timeval *) NULL); *************** *** 358,369 **** --count; } - /* - * Check to make sure there are no exiting children that - * we have not yet reapped and read the last of there input. - */ - debugmsg(DM_CALL, "waitup() calling reap\n"); - reap(); #else /* !defined(HAVE_SELECT) */ /* --- 357,362 ---- /a/data/src% From jtt@pizza.cs.columbia.edu Fri Oct 16 10:07:56 1992 Return-Path: Received: from cs.columbia.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA24382; Fri, 16 Oct 92 10:07:56 PDT Received: from pizza.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA18587; Fri, 16 Oct 1992 13:07:54 -0400 Received: by pizza.cs.columbia.edu (4.1/SMI-4.1+) id AA00399; Fri, 16 Oct 92 13:07:53 EDT Date: Fri, 16 Oct 92 13:07:53 EDT From: jtt@pizza.cs.columbia.edu (James Tanis) Message-Id: <9210161707.AA00399@pizza.cs.columbia.edu> To: rdist@usc.edu Subject: Piped distfile bug. HI folks, I recently began testing beta6 prior to installing it at our site and quickly discovered what I believe is a slight bug in rdist.c when you pipe the distfile into rdist. Here are the vitals: rdist.new -V Version 6.0beta.6 - Protocol Version 6, Release 6.0beta, Patch level 6 Sun4m rdisting to a sun4c -- SunOS 4.1.2 on both machines. The (redacted) command line (worth looking at) cat distfile | rdist -m [test host] -f - [command name] The problem actually doesn't seem to involve the message facilities at all (which is why I didn't include them in the command line), but rather the way rdist deals with the issue of child-reaping given that the distfile has come across stdin *not* from a file (though it looks a bit silly in this example, we have good reasons for cat'ing the distfile across a pipe). The symptom is, quite simply, I received no output to stdout whatsoever. I believe the scenario runs like this. Rdist begins and while parsing the input (for *this* command) sets fin=stdin (line 156 in rdist.c). Once it completes parsing the distfile it fclose(fin) (line 222 in rdist.c). Now it chugs along and eventually starts to fork children and wants to set up a one-way (child-to-parent) pipe where the child will queue all of it's output until reaped at death when the parent reads the entire pipe at once. In *this* situation, when the parent calls pipe() prior to forking the first child, the kernel returns 0 as the `incoming' [PIPE_READ] descriptor (0 is the first one available). All of this is just peachy and everything proceeds normally from there until the child dies. Now the parent wants to read the all output that has accumulated in the queue but first checks to see if the CHILD structure it wants to use appears valid. If the read descriptor is <=0 rdist returns from readchild() without attempting a read (around 170ff in child.c). Here's a patch that cleared the problem for the above command line. It's a bit unpleasant since it leaves the distfile input pipe hanging around far longer than necessary. I tried doing a simple fdopen(fileno(stdin), "r") but to know avail, and I don't think allowing the kernel to clean up the pipe is worth opening some arbitrary file somewhere just so we can reserve descriptor 0. An alternative would be to modify the check in readchild to < 0 (instead of <=0), but I thought that Michael Cooper might have had a very good reason for that test, so I didn't tamper with it. ----- Patch -------- *** rdist.c.orig Fri Oct 16 11:34:11 1992 --- rdist.c Fri Oct 16 11:33:34 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 1.1 1992/10/16 00:59:32 jtt Exp $"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: rdist.c,v 1.4 1992/10/16 15:33:33 jtt Exp $"; static char sccsid[] = "@(#)main.c 5.1 (Berkeley) 6/6/85"; *************** *** 279,285 **** if (fin == NULL) fin = opendist(distfile); (void) yyparse(); ! (void) fclose(fin); if (nerrs == 0) docmds(dsthostc, dsthosts, realargc-optind, &realargv[optind]); --- 279,286 ---- if (fin == NULL) fin = opendist(distfile); (void) yyparse(); ! if ( fin != stdin ) /* Don't return descr 0 to the kernel. */ ! (void) fclose(fin); if (nerrs == 0) docmds(dsthostc, dsthosts, realargc-optind, &realargv[optind]); I also noticed that rdist strips the `+' from the tails of filenames in checkcmd which only contains code if NFS_CHECK is configured at compile (which of course is the default and I leave in). Does rdist watch for the plus in any other piece of code? Or does it simply break if you run an rdist without NFS_CHECK using a distfile that includes `plused' files. If this *is* the policy than why not make checkcmd a NOOP if NFS_CHECK is not selected (thus saving the overhead a bunch of subroutine calls). A simple #define in defs.h should do it. Or are most compilers today sophisticated enough to optimize the calls out of existence? /jtt jtt@cs.columbia.edu From neal@ctd.comsat.com Fri Oct 16 10:25:52 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA25243; Fri, 16 Oct 92 10:25:52 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfvQm-0003TdC; Fri, 16 Oct 92 13:25 EDT Message-Id: Date: Fri, 16 Oct 92 13:25 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist@usc.edu Subject: /tmp/rdistxxx files not removed In-Reply-To: References: Just one more little problem I haven't tracked down yet. /tmp/rdist.... files are not being removed. Don't know why yet. Asking when [Saddam Hussein] will be overthrown is like asking when the economy's coming back. -- An aide to President Bush. From neal@ctd.comsat.com Fri Oct 16 12:06:10 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA29791; Fri, 16 Oct 92 12:06:10 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mfwzt-0003TdC; Fri, 16 Oct 92 15:06 EDT Message-Id: Date: Fri, 16 Oct 92 15:06 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist@usc.edu Subject: /tmp/rdistxxx files, PATCH I think this may be the right fix for this problem. Someone else, please verify this. ================================================================== RCS file: RCS/docmd.c,v retrieving revision 1.1 diff -c -r1.1 docmd.c *** 1.1 1992/10/16 14:59:20 --- docmd.c 1992/10/16 19:01:05 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 1.1 1992/10/16 14:59:20 neal Exp neal $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: docmd.c,v 6.37 1992/10/07 23:41:20 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 934,939 **** --- 934,940 ---- message(MT_INFO, "updating of %s finished", currenthost); closeconn(); + cleanup(); exit(nerrs); } ========================================================= Speaking as a man, it's not a woman's issue. Us men are tired of losing our women -- Vice President Dan Quayle talking about breast cancer From jtt@pizza.cs.columbia.edu Fri Oct 16 13:11:47 1992 Return-Path: Received: from cs.columbia.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA02524; Fri, 16 Oct 92 13:11:47 PDT Received: from pizza.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA25978; Fri, 16 Oct 1992 16:11:40 -0400 Received: by pizza.cs.columbia.edu (4.1/SMI-4.1+) id AA01206; Fri, 16 Oct 92 16:11:39 EDT Date: Fri, 16 Oct 92 16:11:39 EDT From: jtt@pizza.cs.columbia.edu (James Tanis) Message-Id: <9210162011.AA01206@pizza.cs.columbia.edu> To: rdist@usc.edu Subject: rdista patch. Neal's previous patch led to this slight extension. You also have to patch the single-threaded code to cover the -F option. I was surprised that the notify file is only created by the child process. Are the notify files intended to demultiplex messags from the children? I added a call to cleanup() from the parent just in case it kept something open on /tmp/rdistXXXX too. This patch is against virgin docmd.c code 36c36 < "$Id: docmd.c,v 1.1 1992/10/16 04:27:41 jtt Exp $"; --- > "$Id: docmd.c,v 1.5 1992/10/16 20:00:20 jtt Exp jtt $"; 815c815 < docmdhost(cmd, &argv[i]); --- > docmdhost(cmd, &argv[i]); 936a937 > cleanup(); 949,953c950,957 < } else if (!nflag) < /* < * We're single-threaded so close down current connection < */ < closeconn(); --- > cleanup(); > } else if (!nflag) { > /* > * We're single-threaded so close down current connection > */ > closeconn(); > cleanup(); > } /jtt From mcooper@ucs.usc.edu Fri Oct 16 13:28:05 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA03210; Fri, 16 Oct 92 13:28:05 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA12618; Fri, 16 Oct 92 13:27:53 PDT Sender: "Michael A. Cooper" Date: Fri, 16 Oct 92 13:27:52 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: DANGER - rdist-6.0beta.6 AMNESIA In-Reply-To: Your message of Wed, 14 Oct 92 11:30 EDT Message-Id: > > In child.c line 321 change to: > debugmsg(DM_MISC, "waitup() Call select(%d)\n", activechildren); > > > Since Bush became president... > Mean annual income of the wealthiest 5% of US families: +$7,286 (up 5%) > Mean annual income of the poorest one-fifth: -$54 (down .5%) > Fixed. Thanks. mike From mcooper@ucs.usc.edu Fri Oct 16 13:31:05 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA03418; Fri, 16 Oct 92 13:31:05 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA12630; Fri, 16 Oct 92 13:31:00 PDT Sender: "Michael A. Cooper" Date: Fri, 16 Oct 92 13:30:59 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: rdist6.0beta6/hpux FIXED! In-Reply-To: Your message of Fri, 16 Oct 92 10:39 EDT Message-Id: > In child.c several things are fixed. Now it appears to be working OK > for me. I *don't* think this is HPUX-specific. I think it is a > timing problem! > > 1) trivial list-handling mistake It seems I goofed installing the first version of this you sent. It DOES work. My apologies. > > 2) Only call removechild() from reap(). > > 3) Don't call reap(). Let SIGCHLD call reap(). This is the important > change. We only remove a child process when SIGCHILD tells us a child > has exited. > > 4) Trivial %d missing for debugmsg. > > You may want to remove the comment before waitup() which says "Wait > up for children to exit". if HAVE_SELECT, it's really waiting for > data to be available for reading. > All looks good. Thanks! mike From mcooper@ucs.usc.edu Fri Oct 16 13:32:07 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA03443; Fri, 16 Oct 92 13:32:07 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA12635; Fri, 16 Oct 92 13:32:03 PDT Sender: "Michael A. Cooper" Date: Fri, 16 Oct 92 13:32:03 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: jtt@pizza.cs.columbia.edu (James Tanis) Cc: rdist@usc.edu Subject: Re: Piped distfile bug. In-Reply-To: Your message of Fri, 16 Oct 92 13:07:53 EDT Message-Id: Right you are. I've applied your "fin != stdin" test. I've also changed checkcmd() to always strip '+' from hostnames for consistancy. mike From jtt@pizza.cs.columbia.edu Fri Oct 16 13:48:26 1992 Return-Path: Received: from cs.columbia.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA04081; Fri, 16 Oct 92 13:48:26 PDT Received: from pizza.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA27907; Fri, 16 Oct 1992 16:48:25 -0400 Received: by pizza.cs.columbia.edu (4.1/SMI-4.1+) id AA01358; Fri, 16 Oct 92 16:48:24 EDT Date: Fri, 16 Oct 92 16:48:24 EDT From: jtt@pizza.cs.columbia.edu (James Tanis) Message-Id: <9210162048.AA01358@pizza.cs.columbia.edu> To: rdist@usc.edu Subject: rdista patch After reviewung the debugging output from -D, it's clear that the parent *does* create the tmpfile. So you should cleanup in all three places. The calls to the child should remain to insure that they close their inherited descriptors appropriately. /jtt From mcooper@ucs.usc.edu Fri Oct 16 14:22:19 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA03494; Fri, 16 Oct 92 13:33:11 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA12640; Fri, 16 Oct 92 13:33:07 PDT Sender: "Michael A. Cooper" Date: Fri, 16 Oct 92 13:33:07 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: /tmp/rdistxxx files, PATCH In-Reply-To: Your message of Fri, 16 Oct 92 15:06 EDT Message-Id: Yup, that works. You also need a cleanup() at the end of docmd.c: } else if (!nflag) { /* * We're single-threaded so close down current connection */ closeconn(); cleanup(); } mike From mcooper@ucs.usc.edu Fri Oct 16 14:53:44 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA07182; Fri, 16 Oct 92 14:53:44 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA12929; Fri, 16 Oct 92 14:53:41 PDT Sender: "Michael A. Cooper" Date: Fri, 16 Oct 92 14:53:41 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist@usc.edu Subject: Rdist 6.0beta.7 Message-Id: Due to the number of bugs in 6.0beta.6, here's 6.0beta.7. It should be much more stable than the last release, but probably still has problems. Thanks to all those reporting and fixing those bugs! mike Fri Oct 16 13:01:41 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.0beta.7. * Update rdist.1 to more fully describe new message handling system. * Lower syslog logging levels to be mostly LOG_INFO. * Don't explicitly call reap(). Let SIGCHLD call reap(). (Neal Becker) * Only call removechild() from reap(). (Neal Becker) * Fix trivial child list-handling mistake. (Neal Becker) * Call cleanup() to remove /tmp/rdist* files. (Neal Becker) * Remove extraneous debugging info in getnlstr(). * Don't close distfile file descriptor if it's stdin. (James Tanis) * Always strip '+' from hostnames to be consistant. (James Tanis) Thu Oct 15 10:59:14 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem with buffer being overwritten in "chown from ..." message. * Modified rdistcfilter to lexically sort messages. * Fix argument type mismatch in getmountent() which cause core dump when filesystem free space checking was enabled. Wed Oct 14 11:17:45 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix argument mismatch error in call to messae() which could result in a core dump. * Fix bug with directories almost always being reported with -y as "remote copy is newer". * Change message output format (again) to make both normal messages and error messages consistant. * Only check file mtime and size if file type is "regular". * Fix mismatched parameters in call to debugmsg(). (Neal Becker) From @ee.udel.edu,@degenerate.ee.udel.edu:scott@udel.edu Sun Oct 18 16:16:22 1992 Return-Path: <@ee.udel.edu,@degenerate.ee.udel.edu:scott@udel.edu> Received: from louie.udel.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA08720; Sun, 18 Oct 92 16:16:22 PDT Received: from snow-white.ee.udel.edu by louie.udel.edu id aa19686; 18 Oct 92 19:14 EDT Received: from louie.udel.edu by snow-white.ee.udel.edu id aa26068; 18 Oct 92 23:10 GMT Received: from snow-white.ee.udel.edu by degenerate.ee.udel.edu id aa11981; 18 Oct 92 23:08 GMT To: mcooper@usc.edu Cc: rdist@usc.edu Subject: Re: Rdist 6.0beta.7 In-Reply-To: Your message of "Fri, 16 Oct 92 14:53:41 PDT." Date: Sun, 18 Oct 92 19:08:20 -0400 From: Doke Message-Id: <9210182308.aa11981@degenerate.ee.udel.edu> )Due to the number of bugs in 6.0beta.6, here's 6.0beta.7. Here's a diff against 6.0beta.7 to fix the renamed hardlink bug. Cheers, Doke *** client.c.orig Wed Oct 14 15:53:42 1992 --- client.c Sun Oct 18 18:59:11 1992 *************** *** 60,66 **** --- 60,68 ---- struct linkbuf *ihead = NULL; /* list of files with more than one link */ char buf[BUFSIZ]; /* general purpose buffer */ char target[BUFSIZ]; /* target/source directory name */ + char destbuf[BUFSIZ]; /* destination directory name */ char *ptarget; /* pointer to end of target name */ + char *pdestbuf; /* pointer to end of destbuf name */ char *Tdest; /* pointer to last T dest*/ /* *************** *** 176,182 **** lp->inum = statp->st_ino; lp->devnum = statp->st_dev; lp->count = statp->st_nlink - 1; ! (void) strcpy(lp->pathname, target); if (Tdest) (void) strcpy(lp->target, Tdest); else --- 178,184 ---- lp->inum = statp->st_ino; lp->devnum = statp->st_dev; lp->count = statp->st_nlink - 1; ! (void) strcpy(lp->pathname, destbuf); if (Tdest) (void) strcpy(lp->target, Tdest); else *************** *** 377,384 **** { DIRENTRY *dp; DIR *d; ! char *optarget, *cp; ! int len; static void sendit(); /* --- 379,386 ---- { DIRENTRY *dp; DIR *d; ! char *optarget, *opdestbuf, *cp; ! int len, dlen; static void sendit(); /* *************** *** 404,413 **** } optarget = ptarget; len = ptarget - target; while (dp = readdir(d)) { ! if (!strcmp(dp->d_name, ".") || ! !strcmp(dp->d_name, "..")) continue; if (len + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { error("%s/%s: Name too long", target, --- 406,418 ---- } optarget = ptarget; + opdestbuf = pdestbuf; len = ptarget - target; + dlen = pdestbuf - destbuf; while (dp = readdir(d)) { ! if ( *dp->d_name == '.' && ! ( !strcmp(dp->d_name, ".") || ! !strcmp(dp->d_name, "..") ) ) continue; if (len + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { error("%s/%s: Name too long", target, *************** *** 414,425 **** dp->d_name); continue; } ptarget = optarget; *ptarget++ = '/'; cp = dp->d_name; ! while (*ptarget++ = *cp++) ; ptarget--; sendit(dp->d_name, opts); } (void) closedir(d); --- 419,438 ---- dp->d_name); continue; } + if (dlen + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) { + error("%s/%s: Name too long", destbuf, + dp->d_name); + continue; + } ptarget = optarget; + pdestbuf = opdestbuf; *ptarget++ = '/'; + *pdestbuf++ = '/'; cp = dp->d_name; ! while (*pdestbuf++ = *ptarget++ = *cp++) ; ptarget--; + pdestbuf--; sendit(dp->d_name, opts); } (void) closedir(d); *************** *** 428,434 **** --- 441,449 ---- (void) response(); ptarget = optarget; + pdestbuf = opdestbuf; *ptarget = CNULL; + *pdestbuf = CNULL; } /* *************** *** 908,916 **** return; } ! rname = exptilde(target, src); if (rname == NULL) return; ptarget = target; while (*ptarget) ptarget++; --- 923,940 ---- return; } ! if (opts & WHOLE) ! rname = exptilde(destbuf, src ); ! else ! rname = exptilde(destbuf, dest ); if (rname == NULL) return; + for( pdestbuf = destbuf; *pdestbuf; pdestbuf++ ) + ; + + ptarget = exptilde(target, src); + if (ptarget == NULL) + return; ptarget = target; while (*ptarget) ptarget++; *************** *** 924,940 **** rname++; destdir = 1; } else { ! rname = strrchr(target, '/'); ! /* Check if no '/' or target ends in '/' */ if (rname == NULL || rname+1 == NULL || *(rname+1) == CNULL) ! rname = target; else rname++; } ! debugmsg(DM_MISC, "target = %s, rname = %s\n", target, rname); /* * Pass the destination file/directory name to remote. --- 948,966 ---- rname++; destdir = 1; } else { ! rname = strrchr(destbuf, '/'); ! /* Check if no '/' or destbuf ends in '/' */ if (rname == NULL || rname+1 == NULL || *(rname+1) == CNULL) ! rname = destbuf; else rname++; } ! debugmsg(DM_MISC, "target = %s, destbuf = %s, rname = %s\n", ! target, destbuf, rname); ! /* * Pass the destination file/directory name to remote. From rsalz@osf.org Mon Oct 19 06:50:38 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA02702; Mon, 19 Oct 92 06:50:38 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA02234; Mon, 19 Oct 92 09:50:35 -0400 Received: by earth.osf.org (5.64/4.7) id AA04145; Mon, 19 Oct 92 09:50:34 -0400 Date: Mon, 19 Oct 92 09:50:34 -0400 From: rsalz@osf.org Message-Id: <9210191350.AA04145@earth.osf.org> To: mcooper@usc.edu, neal@ctd.comsat.com Subject: Re: rdist6.0beta6/hpux FIXED! Cc: rdist@usc.edu >3) Don't call reap(). Let SIGCHLD call reap(). This is the important >change. We only remove a child process when SIGCHILD tells us a child >has exited. This change worries me. SIGCHLD should just set a flag (of type sig_atomic_t if that typedef exists) and the main loop should reap() if the flag is set. From neal@ctd.comsat.com Mon Oct 19 09:26:58 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA07907; Mon, 19 Oct 92 09:26:58 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mgzwL-0003TdC; Mon, 19 Oct 92 12:26 EDT Message-Id: Date: Mon, 19 Oct 92 12:26 EDT From: neal@ctd.comsat.com (Neal Becker) To: rsalz@osf.org, mcooper@usc.edu Cc: rdist@usc.edu Subject: Proposal for changes to child.c In-Reply-To: <9210191437.AA04239@earth.osf.org> References: <9210191437.AA04239@earth.osf.org> This patch to child.c for rdist6.0beta7 is in response to rsalz comments. There are numerous changes, the main thing is to avoid doing serious work (like calls to malloc and free) in signal handler. -------------------------------------------------------------- RCS file: RCS/child.c,v retrieving revision 6.5 diff -c -r6.5 child.c *** 6.5 1992/10/16 20:24:42 --- child.c 1992/10/19 16:14:00 *************** *** 50,55 **** --- 50,60 ---- #include #include + typedef enum _PROCSTATE { + PSrunning, + PSdead + } PROCSTATE; + /* * Structure for child rdist processes mainted by the parent */ *************** *** 57,62 **** --- 62,68 ---- char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ int c_pid; /* Process ID */ + PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; typedef struct _child CHILD; *************** *** 64,95 **** static CHILD *childlist = NULL; /* List of children */ int activechildren = 0; /* Number of active children */ extern int maxchildren; /* Max active children */ ! /* ! * This routine can be called twice for the same child, ! * so we take care not to do things twice for the same child. ! */ static void removechild(child) CHILD *child; { debugmsg(DM_CALL, "removechild(%s, %d, %d) start", child->c_name, child->c_pid, child->c_readfd); ! if (child->c_name) { ! (void) free(child->c_name); ! child->c_name = NULL; ! ! --activechildren; ! } ! ! if (child->c_readfd > 0) { ! (void) close(child->c_readfd); ! child->c_readfd = -1; ! } ! ! if (child->c_pid) ! child->c_pid = 0; ! debugmsg(DM_CALL, "removechild() end"); } --- 70,122 ---- static CHILD *childlist = NULL; /* List of children */ int activechildren = 0; /* Number of active children */ extern int maxchildren; /* Max active children */ + static int NeedScan = FALSE; ! static void ChildScan() { ! /* ! * Find the child that just exited, read any unread ! * input, then remove it from the list of active children. ! */ ! register CHILD *pc; ! ! debugmsg(DM_CALL, "ChildScan() start"); ! ! for (pc = childlist; pc; pc = pc->c_next) ! if (pc->c_state == PSdead) { ! readchild( pc ); ! removechild( pc ); ! } ! NeedScan = FALSE; ! debugmsg(DM_CALL, "ChildScan() end"); ! } ! static void removechild(child) CHILD *child; { + CHILD *pc, *prevpc; + debugmsg(DM_CALL, "removechild(%s, %d, %d) start", child->c_name, child->c_pid, child->c_readfd); ! for( pc = childlist, prevpc = NULL; pc != NULL; prevpc = pc, pc = pc->c_next ) ! if( pc == child ) break; ! if( pc == NULL ) ! error( "RemoveChild called with bad child %s %d %d", ! child->c_name, child->c_pid, child->c_readfd); ! else { ! int oldmask; ! oldmask = sigblock( sigmask( SIGCHLD ) ); ! if( prevpc != NULL ) ! prevpc->c_next = pc->c_next; ! else ! childlist = pc->c_next; ! sigsetmask( oldmask ); ! ! (void) free(child->c_name); ! --activechildren; ! (void) close(child->c_readfd); ! free( pc ); ! } debugmsg(DM_CALL, "removechild() end"); } *************** *** 106,111 **** --- 133,139 ---- newc->c_name = strdup(child->c_name); newc->c_readfd = child->c_readfd; newc->c_pid = child->c_pid; + newc->c_state = child->c_state; newc->c_next = NULL; return(newc); *************** *** 119,147 **** { register CHILD *pc, *prev; int found; debugmsg(DM_CALL, "addchild() start\n"); ! if (childlist == NULL) ! childlist = copychild(child); ! else { ! /* ! * Try to re-use empty slots in the child list. ! * If none are found, then add to end of list. ! */ ! for (found = FALSE, pc = childlist, prev = NULL; ! !found && pc ; prev = pc, pc = pc->c_next) ! if (pc->c_name == NULL) { ! /* Re-use old slot */ ! pc->c_name = strdup(child->c_name); ! pc->c_readfd = child->c_readfd; ! pc->c_pid = child->c_pid; ! found = TRUE; ! } ! if (!found && prev) ! /* Create a new child */ ! prev->c_next = copychild(child); ! } ++activechildren; --- 147,159 ---- { register CHILD *pc, *prev; int found; + int oldmask; debugmsg(DM_CALL, "addchild() start\n"); ! pc = copychild( child ); ! pc->c_next = childlist; ! childlist = pc; ++activechildren; *************** *** 242,248 **** */ static void reap() { ! register CHILD *pc; int status = 0, pid; debugmsg(DM_CALL, "reap() called\n"); --- 254,260 ---- */ static void reap() { ! register CHILD *pc; int status = 0, pid; debugmsg(DM_CALL, "reap() called\n"); *************** *** 263,281 **** /* * See if a child really exited */ ! if (pid <= 0 || activechildren <= 0) ! break; ! ! /* ! * Find the child that just exited, read any unread ! * input, then remove it from the list of active children. ! */ for (pc = childlist; pc; pc = pc->c_next) ! if (pc->c_pid == pid) { ! readchild(pc); ! removechild(pc); ! break; ! } } /* --- 275,293 ---- /* * See if a child really exited */ ! if (pid == 0) ! break; ! if (pid < 0) { ! if (errno != ECHILD) ! error("Wait failed: %s",SYSERR); ! break; ! } for (pc = childlist; pc; pc = pc->c_next) ! if (pc->c_pid == pid) { ! NeedScan = TRUE; ! pc->c_state = PSdead; ! } ! } /* *************** *** 307,312 **** --- 319,327 ---- debugmsg(DM_CALL, "waitup() start\n"); + if( NeedScan ) + ChildScan(); + if (activechildren <= 0) return; *************** *** 338,344 **** * there are no active children left. */ if (count < 0) { ! if (errno != EINTR && activechildren > 0) error("Select failed reading children input: %s", SYSERR); return; --- 353,359 ---- * there are no active children left. */ if (count < 0) { ! if (errno != EINTR) error("Select failed reading children input: %s", SYSERR); return; *************** *** 415,420 **** --- 430,436 ---- newchild.c_name = childname; newchild.c_readfd = fildes[PIPE_READ]; newchild.c_pid = pid; + newchild.c_state = PSrunning; /* We're not going to write to the child */ (void) close(fildes[PIPE_WRITE]); From mcooper@ucs.usc.edu Mon Oct 19 12:20:13 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA18752; Mon, 19 Oct 92 12:20:13 PDT Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.7) id AA16475; Mon, 19 Oct 92 12:19:45 PDT Sender: "Michael A. Cooper" Date: Mon, 19 Oct 92 12:19:45 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rsalz@osf.org, rdist@usc.edu Subject: Re: Proposal for changes to child.c In-Reply-To: Your message of Mon, 19 Oct 92 12:26 EDT Message-Id: Thanks. I'll look your changes over as soon as I have a chance. It may be a week or so, I'm really busy this week. mike From hirai@cc.swarthmore.edu Mon Oct 19 12:32:47 1992 Return-Path: Received: from oak.cc.swarthmore.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA19325; Mon, 19 Oct 92 12:32:47 PDT Received: by oak.cc.swarthmore.edu (sendmail 5.57/oak05-20-92) id AA12750; Mon, 19 Oct 92 15:32:45 -0400 Received: by gingko.cc.swarthmore.edu (sendmail 5.57/client04-17-92) id AA01733; Mon, 19 Oct 92 15:32:44 -0400 Message-Id: <9210191932.AA01733@gingko.cc.swarthmore.edu> From: hirai@cc.swarthmore.edu (Eiji Hirai) Date: Mon, 19 Oct 1992 15:32:44 -0400 In-Reply-To: Michael A. Cooper "Re: Proposal for changes to child.c" (Oct 19, 12:19pm) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pgp: finger hirai@cc.swarthmore.edu for my PGP 2.0 public key. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist@usc.edu Subject: Re: Proposal for changes to child.c Michael A. Cooper taps on the keyboard: : Thanks. I'll look your changes over as soon as I have a chance. : It may be a week or so, I'm really busy this week. Hopefully, we'll see you in person at LISA! -- obligatory Bush/Quayle bash: "In the past we have tried too much to prevent the making of mistakes." -- Vice President Dan Quayle. From wls@astro.UMD.EDU Fri Oct 23 10:03:56 1992 Received: from capricorn.astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA07811; Fri, 23 Oct 92 10:03:56 PDT Return-Path: Received: by capricorn.astro.umd.edu (5.65c/5.61sWLS) id AA28992; Fri, 23 Oct 1992 13:03:39 -0400 Date: Fri, 23 Oct 1992 13:03:39 -0400 From: wls@astro.UMD.EDU Message-Id: <199210231703.AA28992@capricorn.astro.umd.edu> To: rdist@usc.edu Subject: Problems with "renamed hardlink bug" patch Doke (scott@udel.edu) writes: > Here's a diff against 6.0beta.7 to fix the renamed hardlink bug. > > Cheers, > Doke ... patch to client.c deleted. This broke rdist for me. Several copies of a sun3 /usr that resided on sparcstations and supported diskless sun3 clients were being updated from a sun3 master. The Distfile looked something like this: /usr/${USRFILES} -> ${USRSERVERS} install -R /export/exec/sun3; except /usr/${EXCEPTIONS}; rdist would try to copy files into /export/exec/sun3/sun3 (note the two sun3's) and then delete them. About half a megabyte of log file was generated for each host so affected. Removing the patch fixed the problem. I may have more to say if I figure out what is wrong with the patch. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Fri Oct 23 10:51:46 1992 Received: from crux.astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA10094; Fri, 23 Oct 92 10:51:46 PDT Return-Path: Received: by crux.astro.umd.edu (5.65c/5.61sWLS) id AA09591; Fri, 23 Oct 1992 13:51:44 -0400 Date: Fri, 23 Oct 1992 13:51:44 -0400 From: wls@astro.UMD.EDU Message-Id: <199210231751.AA09591@crux.astro.umd.edu> To: rdist@usc.edu Subject: Portability problems in Rdist 6.0beta.7 I ran into two problems trying to build rdist on a Multiflow Trace 14 running "Multiflow 4.3 BSD TRACE/UNIX* Version 5.0.4:". I think that these portability problems were introduced in the latest changes. 1) The use of waitpid() in child.c. I know that waidpid() is the newer form but the company is defunct so an operating system upgrade is unlikely. I replaced it with a wait3() call. I think a HAVE_WAITPID needs to be defined in config.h ("#if defined(_trace_)" could be used to signal the multiflow). 2) strcasecmp(), used in message.c, is not present. Here is a version of it that I have thrown together that can be used for the "MISSINGOBJS =" statement in the Makefile. --- Cut HERE--- int strcasecmp(s1, s2) register char *s1, *s2; { int c1, c2, diff; while (c2 = *s2++, (c1 = *s1++) != '\0' && c2 != '\0') { if (c1 >= 'A' && c1 <= 'Z') c1 += ('a' - 'A'); if (c2 >= 'A' && c2 <= 'Z') c2 += ('a' - 'A'); if ((diff = c1 - c2) != 0) return(diff); } return(0); } --- Cut HERE --- Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From hirai@cc.swarthmore.edu Fri Oct 23 11:20:27 1992 Return-Path: Received: from oak.cc.swarthmore.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA11639; Fri, 23 Oct 92 11:20:27 PDT Received: by oak.cc.swarthmore.edu (sendmail 5.57/oak05-20-92) id AA17570; Fri, 23 Oct 92 14:20:24 -0400 Received: by gingko.cc.swarthmore.edu (sendmail 5.57/client04-17-92) id AA06751; Fri, 23 Oct 92 14:20:23 -0400 Message-Id: <9210231820.AA06751@gingko.cc.swarthmore.edu> From: hirai@cc.swarthmore.edu (Eiji Hirai) Date: Fri, 23 Oct 1992 14:20:23 -0400 In-Reply-To: wls@astro.UMD.EDU "Portability problems in Rdist 6.0beta.7" (Oct 23, 1:51pm) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pgp: finger hirai@cc.swarthmore.edu for my PGP 2.0 public key. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist@usc.edu Subject: Re: Portability problems in Rdist 6.0beta.7 wls@astro.UMD.EDU taps on the keyboard: : 2) strcasecmp(), used in message.c, is not present. You can get BSD's version from: ftp.uu.net:/systems/unix/bsd-sources/lib/libc/string/strcasecmp.c.Z -- obligatory Bush/Quayle bash: "My position hasn't changed. I am, uh, pro -- pro -- uh, prolife --" -- President George Bush, April 1992. "I happen to think it was right." -- George Bush, March 1980, on his earlier support of Roe vs Wade. From rsalz@osf.org Fri Oct 23 11:33:21 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA12437; Fri, 23 Oct 92 11:33:21 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA05800; Fri, 23 Oct 92 14:33:12 -0400 Received: by earth.osf.org (5.64/4.7) id AA16178; Fri, 23 Oct 92 14:33:11 -0400 Date: Fri, 23 Oct 92 14:33:11 -0400 From: rsalz@osf.org Message-Id: <9210231833.AA16178@earth.osf.org> To: rdist@usc.edu, wls@astro.UMD.EDU Subject: Re: Portability problems in Rdist 6.0beta.7 I think it would be better to use the BSD4.4 strcasecmp if the function is not in the local libc. Pick it up from the INN distribution, among other places... :-) /r$ From wls@astro.UMD.EDU Fri Oct 23 11:51:03 1992 Received: from crux.astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA13400; Fri, 23 Oct 92 11:51:03 PDT Return-Path: Received: by crux.astro.umd.edu (5.65c/5.61sWLS) id AA09702; Fri, 23 Oct 1992 14:49:45 -0400 Date: Fri, 23 Oct 1992 14:49:45 -0400 From: wls@astro.UMD.EDU Message-Id: <199210231849.AA09702@crux.astro.umd.edu> To: rdist@usc.edu Subject: Re: Portability problems in Rdist 6.0beta.7 The reason I included an implementation of strcasecmp was in case there were any copyright issues. Its not a big function. I guess that if rdist will be in BSD4.4 anyway then copyright isn't an issue. I think that the rdist distribution should include a strcasecmp for those machines that it is not in the libc. After all a regex.c (a much bigger function) is included. --- Bill Sebok From mcooper@ucs.usc.edu Mon Oct 26 13:40:16 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.2) id AA16879; Mon, 26 Oct 92 13:40:16 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA25377; Mon, 26 Oct 92 13:40:14 PST Sender: "Michael A. Cooper" Date: Mon, 26 Oct 92 13:40:14 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: New rdist lists Message-Id: I've renamed the "rdist@usc.edu" list to be "rdist-dev@usc.edu" and created a new list called "rdist-announce@usc.edu". Below are the discriptions. If you wish to move from one list to the other, please let me know. The mail archives are on usc.edu for ftp as pub/rdist/rdist-announce.archive pub/rdist/rdist-dev.archive mike From mcooper@ucs.usc.edu Thu Oct 29 11:39:14 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.4) id AA11544; Thu, 29 Oct 92 11:39:14 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA01330; Thu, 29 Oct 92 10:39:38 PST Sender: "Michael A. Cooper" Date: Thu, 29 Oct 92 10:39:37 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-announce@usc.edu Subject: Rdist version 6.0beta.8 released Message-Id: Version 6.0beta.8 is now out for ftp on usc.edu as /pub/rdist/rdist.tar.Z. This version seems pretty usable. I would recommend people try to actually run it. The only major change, besides all the bug fixes, is the addition of the -o option. This is intended to replace all the individual -X options (like -R, -y, -O, etc) for both the command line and distfiles. The main reason for this is that we were running out of letters in the alphabet for new options. The old options are still supported, so everything should be backwards compatible. I'd like to end the beta test of 6.0 by Thanksgiving and announce a solid release at that time. I'm putting a hold on any new features/enhancements until version 6.1. mike Thu Oct 29 09:59:14 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.0beta.8. Tue Oct 27 10:19:11 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Add support for Multiflow Trace 4.3BSD. (wls) * Make wait() configurable and add support for wait3(). * Include strcasecmp.c in distribution. * Cleanup child handling based on code/suggestions from Neal Becker, Rich Salz, and Chris Torek. * Don't print hostname in "Response time out" message since error() handles that. * Add -onochkowner,nochkgroup options. When enabled, no check of a file's user (nochkowner) or group (nochkgroup) ownership is performed. * Prepend DO_ to dist option macros. * Implement new -o to replace all the -X options. * Actually make error messages work by default. * Change fchog() to always print unknown users. * Change fchog() to always print name of target file for messages. From dpk@fid.morgan.com Thu Nov 5 12:36:52 1992 Return-Path: Received: from gateway.morgan.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA05045; Thu, 5 Nov 92 12:36:52 PST Received: from Morgan.COM ([138.20.2.27]) by gateway.morgan.com with SMTP id <41390>; Thu, 5 Nov 1992 15:36:23 -0500 Received: from foreign.Morgan.COM by Morgan.COM id AA13274; Thu, 5 Nov 92 15:36:07 EST Date: Thu, 5 Nov 1992 15:36:07 -0500 From: dpk@fid.Morgan.COM (Doug Kingston) Message-Id: <9211052036.AA13274@Morgan.COM> To: rdist@usc.edu Subject: Infinite loop on stderr write error Version 6.0beta.8 - Protocol Version 6, Release 6.0beta, Patch level 8 The following infinite loop is possible if you take a SIGPIPE on stderr. It would appear that it assumes that a SIGPIPE is due to the daemon going going away, when in fact it could come from other file descriptors as well. A SIGPIPE on stderr needs to be handled better (terminate?). -Doug- - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) write (2, "cs1: local error: Lost connectio".., 41) = -1 EPIPE (Broken pipe) gettimeofday (0xf7ffe208, 0) = 0 getpid () = 25964 sendto (8, "<30>Nov 5 15:27:29 rdist.new[25".., 79, 0, 0x27e48, 16) = 79 getpid () = 25964 stat ("/tmp/rdista25964", 0xf7ffeac8) = -1 ENOENT (No such file or directory) open ("/tmp/rdista25964", 03001, 0666) = 3 ioctl (3, 0x40125401, 0xf7ffdbd4) = -1 ENOTTY (Inappropriate ioctl for device) fstat (3, 0xf7ffdc48) = 0 write (3, "cs1: local error: Lost connectio".., 41) = 41 close (3) = 0 unlink ("/tmp/rdista25964") = 0 sigcleanup () = 0 - SIGPIPE (13) From dpk@fid.morgan.com Thu Nov 5 12:57:17 1992 Return-Path: Received: from gateway.morgan.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA05981; Thu, 5 Nov 92 12:57:17 PST Received: from Morgan.COM ([138.20.2.27]) by gateway.morgan.com with SMTP id <41389>; Thu, 5 Nov 1992 15:56:45 -0500 Received: from foreign.Morgan.COM by Morgan.COM id AA13698; Thu, 5 Nov 92 15:56:37 EST Date: Thu, 5 Nov 1992 15:56:37 -0500 From: dpk@fid.Morgan.COM (Doug Kingston) Message-Id: <9211052056.AA13698@Morgan.COM> To: rdist@usc.edu Subject: rdistd can loop too Here's a trace from an rdistd (6.0Beta8) that also loops. -Doug- - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) write (0, "\1ss1: remote error: Lost connect".., 43) = -1 EPIPE (Broken pipe) sigcleanup () = 0 - SIGPIPE (13) From mcooper@ucs.usc.edu Thu Nov 5 16:22:17 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA15271; Thu, 5 Nov 92 16:22:17 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA15054; Thu, 5 Nov 92 16:22:13 PST Sender: "Michael A. Cooper" Date: Thu, 5 Nov 92 16:22:13 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.Morgan.COM (Doug Kingston) Cc: rdist@usc.edu Subject: Re: Infinite loop on stderr write error In-Reply-To: Your message of Thu, 5 Nov 1992 15:36:07 -0500 Message-Id: That's probably due to SIGPIPE being treated just like a SIGCHLD which is incorrect behavior. I'll fix this in the next release. mike From ken@porsche.visix.COM Mon Nov 9 08:38:36 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA17682; Mon, 9 Nov 92 08:38:36 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA13909; Mon, 9 Nov 92 11:38:31 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA09891; Mon, 9 Nov 92 11:38:42 EST Received: by elan.visix.com (5.4.1/5.40/1.0) id AA08425; Mon, 9 Nov 1992 11:37:40 -0500 Date: Mon, 9 Nov 1992 11:37:40 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211091637.AA08425@elan.visix.com> To: rdist-dev@usc.edu Subject: Newbie question Reply-To: ken@porsche.visix.COM [Is there an rdist FAQ somewhere?] I've gotten rdist installed on a subset of our network (I've learned a new reason to hate RISC/os...) and have a question about dist files: I want to create a sub tree .../dist/... which has things that I want to distribute to hosts, but treat dist as /. i.e. dist/bin/foo would go to /bin/foo. How do I do this? I'm not at all clear how install works in this area. Ken From mcooper@ucs.usc.edu Tue Nov 10 15:14:40 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA01087; Tue, 10 Nov 92 15:14:40 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA23109; Tue, 10 Nov 92 15:14:38 PST Sender: "Michael A. Cooper" Date: Tue, 10 Nov 92 15:14:36 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-announce@usc.edu Subject: Rdist version 6.0beta.9 released Message-Id: This release is all bug fixes and portability changes. mike Tue Nov 10 15:09:59 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.0beta.9 Mon Nov 9 13:19:51 1992 Michael A. Cooper (mcooper@acamar.usc.edu) * Use new *_TYPE defines for defining the types of interfaces available for getting filesystem info, non-blocking I/O, wait() function(), and directory routines. * Modify rdistcfilter to wrap list of hosts instead of truncating. * Clarify rdistd being in $PATH in rdist.1. (Mike Urban) * Remove SIGPIPE as SIGCHLD equivilent. * Add -ochksym option. When enabled, this option will cause rdist to act like the original version when dealing with rdisting directories to symlinks. The original rdist simple ignored the condition where the target on a remote host was a symlink when the target on the master was a directory. The new rdist will automatically make the target on the remote host be the same as the master. This option disables this behavior. * Fix bug with notify failing with certain message level flags. * Only send notify mail when things actually change. * Add support for Sequent Dynix 3.1.2. (Ken Dahl) * Add BSDI support. (Ken Dahl & Jonathan Cohn) * Fix argument order to error() in client.c. From ken@porsche.visix.COM Thu Nov 12 21:31:47 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA26028; Thu, 12 Nov 92 21:31:47 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA20217; Fri, 13 Nov 92 00:31:38 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA02414; Fri, 13 Nov 92 00:32:00 EST Received: by elan.visix.com (5.4.1/5.40/1.0) id AA11848; Fri, 13 Nov 1992 00:30:50 -0500 Date: Fri, 13 Nov 1992 00:30:50 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211130530.AA11848@elan.visix.com> To: rdist-dev@usc.edu Subject: Can you except a host like you except a file? Reply-To: ken@porsche.visix.COM Let's say that you've got a list of hosts that are used for a normal distribution, all but one host which is a server, so it shouldn't update one of its files. Can I say something like FILES=(/etc/afile /etc/special_file) HOSTS=( ahost bhost my_server chost ) ${FILES} -> ${HOSTS} install; except my_server; notify; ${FILES} -> ( my_server ) install; except /etc/special_file; notify; Why would I want to do this? I have a large list of macros for hosts, classified by OS/architecture and "my_server" has several other brethren. It would be more logical (to me) to include my_server in the list of comon hosts, then except it out when I don't want it (and then add a special command set for my_server). Of course, as long as I use lots of comments, I can work around it. What do y'all think? Ken -- Ken Mayer, Workgroup Alchemist ken@visix.com Visix Software Inc./703.758.8230 Bene Vivere Ultio Optima --- Living Well is the Best Revenge From wls@astro.UMD.EDU Fri Nov 13 07:56:36 1992 Received: from crux.astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA14410; Fri, 13 Nov 92 07:56:36 PST Return-Path: Received: by crux.astro.umd.edu (5.65c/5.61sWLS) id AA13819; Fri, 13 Nov 1992 10:49:50 -0500 Date: Fri, 13 Nov 1992 10:49:50 -0500 From: wls@astro.UMD.EDU Message-Id: <199211131549.AA13819@crux.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: Can you except a host like you except a file? I second that suggestion. I have long wanted an "except_host" command. The most general thing (probably some work to implement), might have syntax something like: except_host $(HOSTLIST) [ $(FILELIST) ]; The optional second argument excluding those hosts for just that list of files. I have a program I use with rdist called maintlinks (anonymous ftp from astro.umd.edu in progs/maintlinks2.1.tar.Z), whose main, but not only, purpose is to maintain lists of symbolic links, that makes extensive use of a similar feature. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From neal@ctd.comsat.com Fri Nov 13 08:05:05 1992 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA14676; Fri, 13 Nov 92 08:05:05 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #4) id m0mq3Vx-0003TdC; Fri, 13 Nov 92 11:04 EST Message-Id: Date: Fri, 13 Nov 92 11:04 EST From: neal@ctd.comsat.com (Neal Becker) To: wls@astro.UMD.EDU Cc: rdist-dev@usc.edu Subject: Re: Can you except a host like you except a file? In-Reply-To: <199211131549.AA13819@crux.astro.umd.edu> References: <199211131549.AA13819@crux.astro.umd.edu> What about {list} - host? Why can't you use that? I'm opposed to these unsupervised weekend furloughs for first-degree murderers. -- George Bush, asked whether the Pledge of Allegiance would be his only campaign issue in 1988. From wls@astro.UMD.EDU Fri Nov 13 08:16:36 1992 Received: from astro.umd.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA15117; Fri, 13 Nov 92 08:16:36 PST Return-Path: Received: by astro.astro.umd.edu (5.65c/5.61sWLS) id AA12196; Fri, 13 Nov 1992 11:16:09 -0500 Date: Fri, 13 Nov 1992 11:16:09 -0500 From: wls@astro.UMD.EDU Message-Id: <199211131616.AA12196@astro.astro.umd.edu> To: neal@ctd.comsat.com Subject: Re: Can you except a host like you except a file? Cc: rdist-dev@usc.edu > What about {list} - host? Why can't you use that? > neal@ctd.comsat.com Sorry, I forgot about that. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From mcooper@ucs.usc.edu Fri Nov 13 09:36:18 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA18389; Fri, 13 Nov 92 09:36:18 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA27233; Fri, 13 Nov 92 09:36:14 PST Sender: "Michael A. Cooper" Date: Fri, 13 Nov 92 9:36:13 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: ken@porsche.visix.COM Cc: rdist-dev@usc.edu Subject: Re: Can you except a host like you except a file? In-Reply-To: Your message of Fri, 13 Nov 1992 00:30:50 -0500 Message-Id: You can do that with the "+" and "-" macro syntax: ${FILES} -> ${HOSTS} - myserver install ; notify ; mike From ken@porsche.visix.COM Fri Nov 13 11:04:44 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA21801; Fri, 13 Nov 92 11:04:44 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25268; Fri, 13 Nov 92 14:04:09 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA00767; Fri, 13 Nov 92 14:04:30 EST Received: by elan.visix.com (5.4.1/5.40/1.0) id AA12413; Fri, 13 Nov 1992 14:03:20 -0500 Date: Fri, 13 Nov 1992 14:03:20 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211131903.AA12413@elan.visix.com> To: rdist-dev@usc.edu In-Reply-To: Neal Becker's message of Fri, 13 Nov 92 11:04 EST Subject: Can you except a host like you except a file? Reply-To: ken@porsche.visix.COM Yes, the answer is: ${FILES} -> ${HOSTS} - excepted_host ... It's in the FM, but I didn't make the connection. Thanks for all who responded. Ken From jtt@chestnut.cs.columbia.edu Fri Nov 13 12:30:47 1992 Return-Path: Received: from cs.columbia.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA25120; Fri, 13 Nov 92 12:30:47 PST Received: from chestnut.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA26728; Fri, 13 Nov 1992 15:29:30 -0500 Received: by chestnut.cs.columbia.edu (4.1/SMI-4.1+) id AA12426; Fri, 13 Nov 92 15:29:29 EST Date: Fri, 13 Nov 92 15:29:29 EST From: jtt@chestnut.cs.columbia.edu (James Tanis) Message-Id: <9211132029.AA12426@chestnut.cs.columbia.edu> To: wls@astro.UMD.EDU Cc: rdist-dev@usc.edu Subject: Re: Can you except a host like you except a file? In-Reply-To: <199211131549.AA13819@crux.astro.umd.edu> References: <199211131549.AA13819@crux.astro.umd.edu> >>>>> On Fri, 13 Nov 1992 10:49:50 -0500, wls@astro.UMD.EDU said: w> I second that suggestion. I have long wanted an "except_host" w> command. The most general thing (probably some work to w> implement), might have syntax something like: w> except_host $(HOSTLIST) [ $(FILELIST) ]; w> The optional second argument excluding those hosts for just that w> list of files. w> I have a program I use with rdist called maintlinks (anonymous w> ftp from astro.umd.edu in progs/maintlinks2.1.tar.Z), whose main, w> but not only, purpose is to maintain lists of symbolic links, w> that makes extensive use of a similar feature. w> Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu I've been working on a seris of extensions that will allow a host to label certain files as 'precious' and alert its rdist master not to update these. The impementation is still in a local beta stage (we're running successfully here at Columbia, but the control is Sparten, the error messages vague, and conditions which we don't run into often largely untested). Essentially, the administor of the target machine sets up a textfile, with a compile configurable name. He/she lists the full pathnames for all the precious files in system on separate lines. When rdistd forks it saves the stat info for each of these to compare against every file the master asks it to update or remove (NB you cannot prevent *new* files from arriving with this). If, during an rdist session, the target files matches one of the precious files, the master recieves an alert and the operation is aborted. The code automaticcally makes the precious configuration file precious. Furthermore the master will never attemp to distribute its own precious configuration file if it has one. Finally the master can overide the whole operation with a command line option. The hacks are in local beta stage right now (read: we're running it here sucessfully, but it's only been tested against situations that we face locally). If anyone is interested in the ridst-beta9 diffs just drop me a line. I'd rather do mailings instead of anon ftp since I don't expect enormous response and then I can keep you updated of new changes. /jtt From mcooper@ucs.usc.edu Fri Nov 13 14:22:01 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA00489; Fri, 13 Nov 92 14:22:01 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.9) id AA27764; Fri, 13 Nov 92 14:22:00 PST Sender: "Michael A. Cooper" Date: Fri, 13 Nov 92 14:21:59 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: List of platforms for rdist Message-Id: I'm putting together a list of all the platforms rdist 6.0 runs on. Please check the README file and let me know what platforms (machine type + OS + OS Version) you have 6.0 running on. Please include any notes you have on each platform. Things like what compiler (cc, gcc), compiler version, etc. mike From weber%willy.usc.edu@usc.edu Fri Nov 13 16:46:14 1992 Return-Path: Received: from willy.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA06021; Fri, 13 Nov 92 16:46:14 PST Received: by willy.usc.edu (4.1/SMI-3.0DEV3) id AA22402; Fri, 13 Nov 92 16:46:11 PST Date: Fri, 13 Nov 1992 16:46:02 PST From: Allan G. Weber To: rdist-dev@usc.edu Subject: Problem compiling rdist on HP systems Message-Id: I'm having a problem getting rdist to compile on an HP 700 running HPUX 8.07. If I compile with the standard cc, it won't link rdist and complains that it can't find "alloca.o" anywhere. Not sure what is happening here since this I can't find a call to alloca anywhere in the code. Anybody know what's happening here? If I compile it with gcc, it won't compile common.c because of some "incompatible pointer type for argument 3 of 'vsprintf'". If I add the line "#undef HAVE_VARARGS" to the hpux section of config.h, then gcc compiles and links it ok. Doing it this way works on both HP700 and HP400 systems. Allan Weber From rsalz@osf.org Mon Nov 16 07:06:56 1992 Return-Path: Received: from postman.osf.org by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA22677; Mon, 16 Nov 92 07:06:56 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA09648; Mon, 16 Nov 92 10:06:54 -0500 Received: by earth.osf.org (5.65/4.7) id AA10831; Mon, 16 Nov 92 10:06:53 -0500 Date: Mon, 16 Nov 92 10:06:53 -0500 From: rsalz@osf.org Message-Id: <9211161506.AA10831@earth.osf.org> To: ken@porsche.visix.COM Subject: Re: Can you except a host like you except a file? Cc: rdist-dev@usc.edu Yes, the answer is: ${FILES} -> ${HOSTS} - excepted_host ... Actually, I think this cliche would be useful ${FILES} -> ${HOSTS} - ${EXCEPTIONS} Because you can set the EXCEPTIONS on the command-line for special cases. From ken@porsche.visix.COM Mon Nov 16 07:46:21 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA23651; Mon, 16 Nov 92 07:46:21 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA10913; Mon, 16 Nov 92 10:45:22 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA20979; Mon, 16 Nov 92 10:45:36 EST Received: by elan.visix.com (5.4.2/5.40/1.0) id AA00813; Mon, 16 Nov 1992 10:45:59 -0500 Date: Mon, 16 Nov 1992 10:45:59 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211161545.AA00813@elan.visix.com> To: rsalz@osf.org Cc: rdist-dev@usc.edu In-Reply-To: rsalz@osf.org's message of Mon, 16 Nov 92 10:06:53 -0500 Subject: Can you except a host like you except a file? Reply-To: ken@porsche.visix.COM -->On Mon, 16 Nov 92 10:06:53 -0500, rsalz@osf.org said: rsalz> Yes, the answer is: rsalz> ${FILES} -> ${HOSTS} - excepted_host rsalz> ... rsalz> Actually, I think this cliche would be useful rsalz> ${FILES} -> ${HOSTS} - ${EXCEPTIONS} rsalz> Because you can set the EXCEPTIONS on the command-line for rsalz> special cases. Agreed. I have another comment for newbies: This is a generalized syntax: ${FILES} -> ( ${HOSTS} bhost ) - ( ${EXCEPTIONS} ahost ) ... NOT ${FILES} -> ( ${HOSTS} bhost - ${EXCEPTIONS} ahost ) Which makes sense, but isn't well labeled in the documentation. The same list operations hold for the left hand side too. Ken -- Ken Mayer, Workgroup Alchemist ken@visix.com Visix Software Inc./703.758.8230 Bene Vivere Ultio Optima --- Living Well is the Best Revenge From ken@porsche.visix.COM Mon Nov 16 07:57:23 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA24090; Mon, 16 Nov 92 07:57:23 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA12292; Mon, 16 Nov 92 10:57:05 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA22050; Mon, 16 Nov 92 10:57:19 EST Received: by elan.visix.com (5.4.2/5.40/1.0) id AA00832; Mon, 16 Nov 1992 10:57:48 -0500 Date: Mon, 16 Nov 1992 10:57:48 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211161557.AA00832@elan.visix.com> To: rdist-dev@usc.edu Subject: Using scripts to create files Reply-To: ken@porsche.visix.COM I use a script to assemble my /etc/passwd, /etc/group, and others from component parts; some parts are local to a machine (i.e. root, news, uucp, etc.) while others are network based (users). I use rdist to deploy the network based data, run a (special) script and then remove the temporary distribution files. I have a feeling that the script will not carry the same ownership, permissions and modification times as if rdist was in direct control of the file. Is there any way to get around this limitation? Ken -- Ken Mayer, Workgroup Alchemist ken@visix.com Visix Software Inc./703.758.8230 Bene Vivere Ultio Optima --- Living Well is the Best Revenge From rouilj@ra.cs.umb.edu Mon Nov 16 08:27:29 1992 Return-Path: Received: from ra.cs.umb.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA24856; Mon, 16 Nov 92 08:27:29 PST Received: by ra.cs.umb.edu id AA22210 (5.65c/IDA-1.4.4 for rdist-dev@usc.edu); Mon, 16 Nov 1992 11:26:35 -0500 From: "John P. Rouillard" Message-Id: <199211161626.AA22210@ra.cs.umb.edu> Subject: Re: Using scripts to create files To: ken@porsche.visix.COM Date: Mon, 16 Nov 92 11:26:35 EST Cc: rdist-dev@usc.edu In-Reply-To: <9211161557.AA00832@elan.visix.com>; from "Ken Mayer" at Nov 16, 92 10:57 am X-Mailer: ELM [version 2.3 PL11] Ken Mayer writes: > > I use a script to assemble my /etc/passwd, /etc/group, and others from > component parts; some parts are local to a machine (i.e. root, news, > uucp, etc.) while others are network based (users). I use rdist to > deploy the network based data, run a (special) script and then remove > the temporary distribution files. This is similiar to what I do except that all of the scripts are run on the master machine, and I have a database that determines/shows which machines have what functions (mailhost, mail backup, news etc). Then I just rdist the files directly. > I have a feeling that the script will not carry the same ownership, > permissions and modification times as if rdist was in direct control > of the file. Is there any way to get around this limitation? I assume you don't want spurious updates to be done to these files. Check out the younger mode. This will not perform an update on a file if the file is younger (newer) than the rdist master. If you want to force a new copy of the file to go out, just touch the rdist master. -- John From ken@porsche.visix.COM Sat Nov 21 17:39:58 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.4) id AA02129; Sat, 21 Nov 92 17:39:58 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28599; Sat, 21 Nov 92 20:39:51 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA17306; Sat, 21 Nov 92 20:40:18 EST Received: by elan.visix.com (5.4.2/5.40/1.0) id AA05953; Sat, 21 Nov 1992 20:40:30 -0500 Date: Sat, 21 Nov 1992 20:40:30 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211220140.AA05953@elan.visix.com> To: rdist@usc.edu Subject: server.c: fchown/fchmod Reply-To: ken@porsche.visix.COM in server.c: static int fchog(fd, file, owner, group, mode) int fd; char *file, *owner, *group; int mode; { ... ok: if ((fd != -1 && fchown(fd, uid, gid) < 0) || chown(file, uid, gid) < 0) message(MT_NOTICE, "%s: chown %d.%d failed: %s", target, uid, gid, SYSERR); else if (mode != -1 && ((fd != -1 && fchmod(fd, mode) < 0) || chmod(file, mode) < 0)) message(MT_NOTICE, "%s: chmod failed: %s", target, SYSERR); return(0); } I'm not sure what the "intent" of this code is. If fd is real (that is, != -1) and fchown()/fchmod() succeeds, then chown()/chmod() is also executed. This seems redundant. Shouldn't the code read: ok: if ((fd != -1 && fchown(fd, uid, gid) < 0) && chown(file, uid, gid) < 0) message(MT_NOTICE, "%s: chown %d.%d failed: %s", target, uid, gid, SYSERR); else if (mode != -1 && ((fd != -1 && fchmod(fd, mode) < 0) && chmod(file, mode) < 0)) message(MT_NOTICE, "%s: chmod failed: %s", target, SYSERR); return(0); In english the new code reads, "if both fchown (fchmod) and chown (chmod) fail then report an error." The original code doesn't hurt anyone -- except that I am porting rdist to a Sequent box running DYNIX/ptx (V1.3.1, a System V Un*x) which doesn't have fchown or fchmod. I hacked a macro for fchown & fchmod to return -1, that way the second clause always gets executed (whether fd = -1 or not). I'll send the diffs as soon as I am finished here. P.S. Do you have a regression test suite? I'd like to run one if I can to check my port. Ken -- Ken Mayer, Workgroup Alchemist ken@visix.com Visix Software Inc./703.758.8230 If you want it yesterday you've got to give me at least a week's notice. From mcooper@ucs.usc.edu Mon Nov 23 11:28:41 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.4) id AA09621; Mon, 23 Nov 92 11:28:41 PST Received: by acamar.usc.edu (4.1/SMI-3.0DEV3-ucs+2.10) id AA12631; Mon, 23 Nov 92 11:28:30 PST Sender: "Michael A. Cooper" Date: Mon, 23 Nov 92 11:28:29 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: ken@porsche.visix.COM Cc: rdist@usc.edu Subject: Re: server.c: fchown/fchmod In-Reply-To: Your message of Sat, 21 Nov 1992 20:40:30 -0500 Message-Id: I believe you are correct. However, since the code is working now, I don't want to change it at the last minute without sufficient testing. I'll put the fix into rdist 6.1. And no, I don't have any real regression tests other than installing things on my machines. I haven't had much time for such things. If anybody wants to contribute such a test suite, please do! mike From ken@porsche.visix.COM Mon Nov 23 13:48:45 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.4) id AA15362; Mon, 23 Nov 92 13:48:45 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07152; Mon, 23 Nov 92 16:48:30 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA27304; Mon, 23 Nov 92 16:48:55 EST Received: by elan.visix.com (5.4.2/5.40/1.0) id AA06862; Mon, 23 Nov 1992 16:49:08 -0500 Date: Mon, 23 Nov 1992 16:49:08 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9211232149.AA06862@elan.visix.com> To: mcooper@usc.edu Cc: rdist@usc.edu In-Reply-To: Michael A. Cooper's message of Mon, 23 Nov 92 11:28:29 PST Subject: server.c: fchown/fchmod Reply-To: ken@porsche.visix.COM -->Michael A. Cooper writes: Michael> I believe you are correct. However, since the code is Michael> working now, I don't want to change it at the last minute Michael> without sufficient testing. I'll put the fix into rdist Michael> 6.1. Michael> And no, I don't have any real regression tests other than Michael> installing things on my machines. I haven't had much time Michael> for such things. If anybody wants to contribute such a test Michael> suite, please do! Michael> mike Thanks. I made the change here and it doesn't seem to break anything (yet). I'll see what I can do about a regression test. Perhaps if some kind soul could bullet item the features that need to be tested... Ken From mcooper@ucs.usc.edu Tue Dec 1 20:41:38 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.5) id AA22797; Tue, 1 Dec 92 20:41:38 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.0) id AA01876; Tue, 1 Dec 92 20:40:22 PST Sender: "Michael A. Cooper" Date: Tue, 1 Dec 92 20:40:22 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.0.0 released Message-Id: 29-Nov-92 22:29:43-GMT,647;000000000001 Date: Sun, 29 Nov 92 14:29:43 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-announce@usc.edu Subject: Rdist 6.0.0 released Message-ID: [ I was going to announce this tonight, but I just discovered the original message didn't make it to most people. ] This is it. Version 6.0.0 is now available. Last chance to say something on it. I plan on posting an announcement to the following groups on Friday (12/4/92): comp.sys.{hp,next.sysadmin,sun.admin} comp.unix.{admin,aix,bsd,solaris,ultrix} I plan on submitting the sources to comp.sources.misc for posting. I would prefer comp.sources.unix, but I would like to see it posted in my lifetime. Comments/suggestions are welcome. mike From ken@porsche.visix.COM Fri Dec 4 10:10:06 1992 Return-Path: Received: from uu2.psi.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.5) id AA02422; Fri, 4 Dec 92 10:10:06 PST Received: from porsche.visix.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA26956; Fri, 4 Dec 92 13:09:59 -0500 Received: from elan.visix.com by porsche.visix.COM (4.1/Visix Software Rev 2.0) id AA07859; Fri, 4 Dec 92 13:10:33 EST Received: by elan.visix.com (5.4.2/5.40/1.0) id AA24670; Fri, 4 Dec 1992 13:10:52 -0500 Date: Fri, 4 Dec 1992 13:10:52 -0500 From: ken@porsche.visix.COM (Ken Mayer) Message-Id: <9212041810.AA24670@elan.visix.com> To: rdist-dev@usc.edu Subject: Why don't cmdspecial's show up Reply-To: ken@porsche.visix.COM Why don't cmdspecial's show up in the update logs that get e-mailed to me? Is this a feature? Ken From mcooper@ucs.usc.edu Fri Dec 4 10:23:41 1992 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.5) id AA02856; Fri, 4 Dec 92 10:23:41 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.0) id AA10469; Fri, 4 Dec 92 10:23:39 PST Sender: "Michael A. Cooper" Date: Fri, 4 Dec 92 10:23:37 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: ken@porsche.visix.COM Cc: rdist-dev@usc.edu Subject: Re: Why don't cmdspecial's show up In-Reply-To: Your message of Fri, 4 Dec 1992 13:10:52 -0500 Message-Id: I assume you're talking about "notify" messages? If so, I dunno off hand. I'll check when I get a chance... mike From mcooper@ucs.usc.edu Fri Jan 1 13:37:56 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.7) id AA27958; Fri, 1 Jan 93 13:37:56 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.0) id AA06227; Fri, 1 Jan 93 13:37:54 PST Sender: "Michael A. Cooper" Date: Fri, 1 Jan 93 13:37:53 PST From: Michael A. Cooper Reply-To: mcooper@ucs.usc.edu To: rdist-dev@ucs.usc.edu Subject: Patch for hardlink bug Message-Id: Here is a patch that should fix the problem with hardlinks not being handled properly when a target is specified to the "install" command. I'm working on a new release (6.1) that I hope to have something ready for testing this month. The timing depends on work and how much skiing I want to do this month. :-) Most of the new stuff is minor bugs and nit picking. The bulk of it will be portability changes and support for new platforms like SVR4. I'm planning on switching to a scheme like the one used with GNU emacs and the individual .h files - one machine specific and one OS specific. The number of portability changes I'm receiving is overloading the current scheme. mike *** /tmp/T0a02453 Thu Dec 31 13:32:22 1992 --- /tmp/T1a02453 Thu Dec 31 13:32:23 1992 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: client.c,v 6.36 1992/11/12 18:53:52 mcooper Exp $"; static char sccsid[] = "@(#)client.c"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: client.c,v 6.37 1992/12/31 21:30:24 mcooper Exp $"; static char sccsid[] = "@(#)client.c"; *************** *** 193,198 **** --- 193,202 ---- struct linkbuf *lp; char *rname; { + debugmsg(DM_MISC, + "sendhardlink: rname = '%s' pathname = '%s' target = '%s'\n", + rname, lp->pathname, lp->target); + if (*lp->target == 0) (void) sendcmd(C_RECVHARDLINK, "%o %s %s", opts, lp->pathname, rname); *************** *** 211,218 **** lname++; } (void) sendcmd(C_RECVHARDLINK, "%o %s/%s %s", ! opts, lp->target, ! lname, rname); } (void) response(); --- 215,221 ---- lname++; } (void) sendcmd(C_RECVHARDLINK, "%o %s/%s %s", ! opts, lp->target, lname, rname); } (void) response(); *************** *** 884,891 **** char *src, *dest; int destdir, opts; { char *rname; - char destcopy[MAXPATHLEN]; if (dest == NULL) { FLAG_OFF(opts, DO_WHOLE); /* WHOLE only useful if renaming */ --- 887,894 ---- char *src, *dest; int destdir, opts; { + static char destcopy[MAXPATHLEN]; char *rname; if (dest == NULL) { FLAG_OFF(opts, DO_WHOLE); /* WHOLE only useful if renaming */ *************** *** 930,936 **** rname++; } ! debugmsg(DM_MISC, "target = %s, rname = %s\n", target, rname); /* * Pass the destination file/directory name to remote. --- 933,940 ---- rname++; } ! debugmsg(DM_MISC, "target = %s rname = %s dest = '%s' destdir = %d\n", ! target, rname, dest, destdir); /* * Pass the destination file/directory name to remote. *************** *** 942,951 **** if (response() < 0) return; ! if (destdir) { (void) strcpy(destcopy, dest); Tdest = destcopy; } sendit(rname, opts); Tdest = 0; } --- 946,962 ---- if (response() < 0) return; ! /* ! * Save the name of the remote target destination if we are ! * in WHOLE mode (destdir > 0) or if the source and destination ! * are not the same. This info will be used later for maintaining ! * hardlink info. ! */ ! if (destdir || (src && dest && strcmp(src, dest))) { (void) strcpy(destcopy, dest); Tdest = destcopy; } + sendit(rname, opts); Tdest = 0; } From tito@di.unipi.it Thu Jan 7 05:56:53 1993 Return-Path: Received: from apollo.di.unipi.it by usc.edu (5.64+/SMI-3.0DEV3-USC+2.7) id AA15939; Thu, 7 Jan 93 05:56:53 PST Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA13176; Thu, 7 Jan 93 14:56:57 +0100 Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA00649; Thu, 7 Jan 93 14:56:27 +0100 Date: Thu, 7 Jan 93 14:56:27 +0100 From: tito@di.unipi.it Message-Id: <9301071356.AA00649@olimpo.di.unipi.it> To: rdist-dev@di.unipi.it Cc: tito@di.unipi.it Subject: BASIC INFO Hy, We are interested in adopting rdist. It seems to be an extremly flexible tool. I feel that could be very useful to give a look at some real rdist configuration file to understand the kind of things that people are actually doing with rdist. Sample files are available somewhere? Anybody can send me his configuration files? Is a FAQ available? I'm not on this mailing list. Please answer directly to me. Tanks a lot, Tito Flagella ------------------------------------------------------------------- Tito Flagella Information Technology Consultant Universita' di Pisa --------------------------------- Dipartimento Informatica email: tito@di.unipi.it Corso Italia 40 fax : +39 (50) 510226 I-56125 Pisa tel : +39 (50) 510263 ------------------------------------------------------------------- From pds@lemming.webo.dg.com Fri Jan 8 09:31:13 1993 Return-Path: Received: from dg-webo.us.dg.com by usc.edu (5.64+/SMI-3.0DEV3-USC+2.7) id AA26305; Fri, 8 Jan 93 09:31:13 PST Received: from lemming by dg-webo (5.4.1/dg-webo-v1) id AA14303; Fri, 8 Jan 1993 12:30:55 -0500 Received: by lemming.webo.dg.com (5.4.1/dg-s01) id AA05112; Fri, 8 Jan 1993 12:30:52 -0500 Date: Fri, 8 Jan 1993 12:30:52 -0500 From: pds@lemming.webo.dg.com (Paul D. Smith) Message-Id: <9301081730.AA05112@lemming.webo.dg.com> To: rdist-dev@lemming.webo.dg.com Subject: Bugs in rdist Before the holidays I got rdist 6.0.0 (plus the hardlink patch) to compile on a DG AViiON running DG/UX. However, I didn't have a chance to try it out; when I did I found a few more bugs--patches below: * child.c:childscan() In ANSI C or a UNIX with a free() which overwrites freed memory; you loop through a linked list where some of the links might be freed, without storing the ->next ptr before the free. * gram.y:insert() and gram.y:makenl() In ANSI C and some UNIX's you may not pass a NULL pointer for a %s format char in any of the *prinf() family (vsprintf, sprintf, fprintf, and printf). This is done in a few places and causes cores. * setargs.c:setargs_settup() In here you set LastArgv to point to the byte beyond the *environment* as well as argv... this wreaks havoc on systems where argv and the environment aren't adjacent to each other; even where they are I don't think it's a good idea to overwrite the environment. I added a constant, KEEP_ENV, which if defined keeps rdist from writing over the end of the environment by setting LastArgv to point to the end of argv space always. Under ANSI it's not even really legal to assume argv is all stored in one big buffer, although it's true in most UNIX implementations. You might want to add another constant which forces the whole process name into argv[0] and nulls out the other argv's, just for systems where this is true. That's it; after that it seems to work OK. Thanks, paul ----- ------------------------------------------------------------------ | Paul D. Smith | paul_smith@dg.com | | Data General Corp. | pds@lemming.webo.dg.com | | Network Systems Development Division | | | Open Network Systems Development | "Pretty Damn S..." | ------------------------------------------------------------------ ------------------------------------------------------------------------------- --- child.c-dist Mon Nov 9 22:17:25 1992 +++ child.c Thu Jan 7 16:32:55 1993 @@ -312,15 +312,17 @@ */ static void childscan() { - register CHILD *pc; + register CHILD *pc, *npc; debugmsg(DM_CALL, "childscan() start"); - for (pc = childlist; pc; pc = pc->c_next) + for (pc = childlist; pc; pc = npc) { + npc = pc->c_next; if (pc->c_state == PSdead) { readchild(pc); removechild(pc); } + } needscan = FALSE; debugmsg(DM_CALL, "childscan() end"); --- gram.y-dist Tue Oct 27 16:16:12 1992 +++ gram.y Thu Jan 7 15:22:44 1993 @@ -412,7 +412,8 @@ register struct namelist *h, *lasth; debugmsg(DM_CALL, "insert(%s, %x, %x, %x) start, files = %s", - label, files, hosts, subcmds, getnlstr(files)); + label!=NULL ? label : "", + files, hosts, subcmds, getnlstr(files)); files = expand(files, E_VARS|E_SHELL); hosts = expand(hosts, E_ALL); @@ -513,7 +514,7 @@ { register struct namelist *nl; - debugmsg(DM_CALL, "makenl(%s)", name); + debugmsg(DM_CALL, "makenl(%s)", name!=NULL ? name: ""); nl = ALLOC(namelist); nl->n_name = name; --- setargs.c-dist Wed Oct 7 14:15:20 1992 +++ setargs.c Fri Jan 8 10:30:22 1993 @@ -73,9 +73,11 @@ /* Save start and extent of argv for setproctitle */ Argv = argv; +#ifndef KEEP_ENV if (i > 0) LastArgv = envp[i-1] + strlen(envp[i-1]); else +#endif LastArgv = argv[argc-1] + strlen(argv[argc-1]); } From jtt@chestnut.cs.columbia.edu Wed Jan 13 16:43:54 1993 Return-Path: Received: from cs.columbia.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.9) id AA03170; Wed, 13 Jan 93 16:43:54 PST Received: from chestnut.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA23980; Wed, 13 Jan 1993 19:43:52 -0500 Received: by chestnut.cs.columbia.edu (4.1/SMI-4.1+) id AA05371; Wed, 13 Jan 93 19:43:49 EST Date: Wed, 13 Jan 93 19:43:49 EST From: jtt@chestnut.cs.columbia.edu (James Tanis) Message-Id: <9301140043.AA05371@chestnut.cs.columbia.edu> To: rdist@chestnut.cs.columbia.edu Cc: ezk@chestnut.cs.columbia.edu Subject: SunOS4.1.3 (Solaris 1.1) lstat bug. Hi folks, Apparently sun has modified the behavior of lstat() in their most recent version 4 release (4.1.3 aka Solaris 1.1). Until now, if one lstat'ed a directory link, one could expect to receive a * link type record if the path did *not* end in a '/' or * directory type record if the path *did* end with a '/'. This is no longer the case. lstat now returns link type in either case. At our site, this broke our distfiles which we wrote to first distribute some links and then to distribute the files that they pointed to. Using the -ofollow option is not acceptable to us since we must support a (path-illogical :-) ) self referencing symlink in the directory we're distributing. The following patch fixes the problem, provided rdist is recompiled with -DSUN_412_COMPAT. The patch (which is probably easier merge by hand :-) ) was generated against a vanilla 6.0.0 client.c source. ----- CUT HERE -------- *** client.c Wed Jan 13 18:18:12 1993 --- client.p Wed Jan 13 18:17:53 1993 *************** *** 457,462 **** --- 457,470 ---- } } + #ifdef SUN_412_COMPAT + if ( target[strlen(target)-1] == '/' && S_ISLNK(stb.st_mode) ) + if ( stat(target, &stb) < 0 ) { + error("%s: stat failed: %s", target, SYSERR); + return; + } + #endif SUN_412_COMPAT + /* * Gather and send basic link info */ ------------------------- While I'm at there is one other bug which I'm fairly certain exists, but someone else should verify it. I noticed it while reading the server.c code, fixed it immediately since I didn't have time to verify it at the time, and have run with the mods ever since. I *did* accidently compile out my changes once and got surprising results which were consistent with the bug I thought I saw, though. When preening a directory the client and server switch roles as we know, and the *receiving* side starts to inquire of the sender what to do with each file. As the code stands, if a single query/action loop fails, the entire process aborts leaving the rest of the directory untouched. Perhaps this was the intended behavior, but it as could result in a partially cleaned directory, I'm not sure that it's proper. The following patch (again created against a vanilla 6.0.0 server.c) should remedy the situation assuming that rdistd is compiled with -DRMDIR_FIX. --- CUT HERE ----- *** server.c Wed Jan 13 18:35:22 1993 --- server.p Wed Jan 13 18:25:05 1993 *************** *** 168,174 **** --- 168,178 ---- struct stat stb; char *optarget; int len; + #ifdef RMDIR_FIX + int failed = 0; + #endif RMDIR_FIX + switch (statb->st_mode & S_IFMT) { case S_IFREG: case S_IFLNK: *************** *** 215,225 **** --- 219,241 ---- continue; } if (removefile(&stb) < 0) + #ifndef RMDIR_FIX return(-1); + #else RMDIR_FIX + failed=1; + #endif RMDIR_FIX } (void) closedir(d); ptarget = optarget; *ptarget = CNULL; + + #ifdef RMDIR_FIX + if ( failed ) { + message(MT_REMOTE|MT_CHANGE,"%s: rmdir failed\n",target); + return (-1) ; + } + #endif RMDIR_FIX + if (rmdir(target) < 0) { error("%s: rmdir failed: %s", target, SYSERR); return(-1); From aad@lovecraft.siemens.com Sun Jan 17 15:48:34 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+2.10.8) id AA24075; Sun, 17 Jan 93 15:48:34 PST Received: from lovecraft.siemens.com by siemens.siemens.com with smtp (Smail3.1.28.1 #5) id m0nDjjK-00199yC; Sun, 17 Jan 93 18:48 EST Received: by lovecraft.siemens.com (4.1/SMI-4.1) id AA20451; Sun, 17 Jan 93 18:48:30 EST Date: Sun, 17 Jan 93 18:48:30 EST From: aad@lovecraft.siemens.com (Anthony Datri) Message-Id: <9301172348.AA20451@lovecraft.siemens.com> To: rdist-dev@usc.edu Subject: cmdspecial bug? cmdspecial doesn't seem to log. For example, if I run x11r5: ( /local/scr/x11r5.sun4.pl21 ) -> ( ${X11R5} ) install; special "if [ ! -h /local/scr/x11r5 ]; then ln -s x11r5.sun4.pl21 /local/scr/x11r5 ; fi "; when /local/scr/x11r5.sun4.pl21/bin/xterm needs to be updated, I get: derlethRoot=>rdist -v -m cadillac cadillac: updating host cadillac cadillac: /local/scr/adm/dns/hosts: Warning: remote copy is newer cadillac: /local/scr/x11r5.sun4.pl21/bin/xterm: need to update cadillac: special "if [ ! -h /local/scr/x11r5 ]; then ln -s x11r5.sun4.pl21 /local/scr/x11r5 ; fi " cadillac: updating of cadillac finished But if I change "special" to "cmdspecial", the action is taken but I don't get the output for it: derlethRoot=>rdist -v -m cadillac cadillac: updating host cadillac cadillac: /local/scr/adm/dns/hosts: Warning: remote copy is newer cadillac: /local/scr/adm/machines: need to update cadillac: /local/scr/x11r5.sun4.pl21/bin/xterm: need to update cadillac: updating of cadillac finished From mcooper@ucs.usc.edu Mon Jan 18 10:18:28 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+2.10.8) id AA22793; Mon, 18 Jan 93 10:18:28 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA07904; Mon, 18 Jan 93 10:18:25 PST Sender: "Michael A. Cooper" Date: Mon, 18 Jan 93 10:18:24 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: aad@lovecraft.siemens.com (Anthony Datri) Cc: rdist-dev@usc.edu Subject: Re: cmdspecial bug? In-Reply-To: Your message of Sun, 17 Jan 93 18:48:30 EST Message-Id: Fixed in the next release. mike From aad@lovecraft.siemens.com Sun Jan 31 13:57:55 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11588; Sun, 31 Jan 93 13:57:55 PST Received: from lovecraft.siemens.com by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nImfT-0019ENC; Sun, 31 Jan 93 16:57 EST Received: by lovecraft.siemens.com (4.1/SMI-4.1) id AA02249; Sun, 31 Jan 93 16:57:09 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Sun, 31 Jan 1993 16:57:08 -0500 (EST) Message-Id: Date: Sun, 31 Jan 1993 16:57:08 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: possible bug in client.c I've noticed that if I have a source file listed twice in a package that the link counts seem to get confused. For example, /local/scr/bin/wrapper has a total of 21 links. I have a target in Distfile that pushes all of them, but if I accidentally include a file twice in that target, the link-count check is confused: cadillac: /local/scr/bin/wrapper: Warning: -3 missing links ls -li on both the source and the target verifies that the link count is in fact just fine. Although it is an admittedly silly idea to have the same source file in a package twice, it would seem to be a good idea to handle it if it happens. I must admit, though, that I don't follow the link-counting process fully, so I can't offer a fix. I'm running production 6.0 to which has been applied the good Mr. Cooper's "Patch for hardlink bug" of 1-1-93. The machines are various Sun 4's running 4.1.x, compilation is with the bundled compiler. ======================================================================8--< From mcooper@ucs.usc.edu Mon Feb 15 19:25:21 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29928; Mon, 15 Feb 93 19:25:21 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA21414; Mon, 15 Feb 93 19:21:17 PST Sender: "Michael A. Cooper" Date: Mon, 15 Feb 93 19:21:17 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.1beta.0 available Message-Id: Rdist version 6.1beta.0 is now available. The major changes since 6.0 include some bug fixes (including the "hardlink" bug), minor additional features, and a lot of portability and configuration changes. This release should be much easier to port to new platforms. For those who ported 6.0 to a new platform which I didn't include in 6.1, please feel free to send me new ports to 6.1. mike From neal@ctd.comsat.com Tue Feb 16 07:01:55 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20088; Tue, 16 Feb 93 07:01:55 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nOTo1-0003TdC; Tue, 16 Feb 93 10:01 EST Message-Id: Date: Tue, 16 Feb 93 10:01 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: real-rdist-announce@usc.edu Subject: Rdist 6.1beta.0 available In-Reply-To: References: rdist6.1beta.0 seems to be working fine here. Nice job! You don't make money in politics. Or, I should say --- you shouldn't. -- Marilyn Quayle. From dbeusee@us.oracle.com Wed Feb 17 01:40:14 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28554; Wed, 17 Feb 93 01:40:14 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11853; Wed, 17 Feb 93 01:40:07 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA24421; Wed, 17 Feb 93 01:33:29 PST Message-Id: <9302170933.AA24421@dbeusee.us.oracle.com> Date: Wed, 17 Feb 93 01:33:29 PST From: Don Beusee To: mcooper@usc.edu Subject: Re: Rdist 6.1beta.0 available Cc: rdist-dev@usc.edu I have ported rdist to the following additional platforms: DYNIX DYNIX/ptx DC/OSx OSx Porting is much easier now - good job! I am including the following complete files in a .shar file (included last): ./config/os-type ./config/mf.pyrOSx ./config/os-pyrOSx.h ./config/mf.dynix ./config/os-dynix.h ./config/os-dcosx.h ./config/mf.dcosx ./config/os-dynixptx.h ./config/mf.dynixptx ./missing/utimes.c And diffs for the following: ./src/docmd.c ./src/filesys.c ./src/message.c note: I pasted the diffs to my mail window - so tabs are lost Here are the diffs: ---------docmd.c---------- *** 1.1 1993/02/17 06:43:16 --- docmd.c 1993/02/17 06:47:06 *************** *** 619,625 **** --- 619,627 ---- register struct namelist *f; register char *cp, **cpp; struct timeval tv[2]; + #ifndef _SEQUENT_ struct timezone tz; + #endif struct stat stb; struct namelist *files = cmd->c_files; struct subcmd *sbcmds = cmd->c_cmds; *************** *** 651,659 **** --- 653,665 ---- subcmds = sbcmds; lastmod = stb.st_mtime; if (!nflag && !IS_ON(options, DO_VERIFY)) { + #ifdef _SEQUENT_ + (void) utime(stamp, (struct utimbuf *)0); + #else (void) gettimeofday(&tv[0], &tz); (void) setfiletime(stamp, (time_t)tv[0].tv_sec, (time_t)tv[0].tv_sec); + #endif } for (f = files; f != NULL; f = f->n_next) { --------end of docmd.c--------- ---------filesys.c---------- *** 1.1 1993/02/17 05:25:23 --- filesys.c 1993/02/17 05:25:41 *************** *** 85,91 **** return(file); } ! if (strlen(pathname) > sizeof(file)+3) { error("%s: Name to large for buffer.", pathname); return((char *) NULL); } --- 85,91 ---- return(file); } ! if ((int)strlen(pathname) > sizeof(file)+3) { error("%s: Name to large for buffer.", pathname); return((char *) NULL); } --------end of filesys.c--------- ---------message.c---------- *** 1.1 1993/02/17 05:40:47 --- message.c 1993/02/17 05:41:08 *************** *** 279,287 **** *cp++ = CNULL; word = optstr; ! if (strlen(word) <= 0) return("No message facility specified"); ! if (strlen(cp) <= 0) return("No message type specified"); if ((msgfac = getmsgfac(word)) == NULL) { --- 279,287 ---- *cp++ = CNULL; word = optstr; ! if ((int)strlen(word) <= 0) return("No message facility specified"); ! if ((int)strlen(cp) <= 0) return("No message type specified"); if ((msgfac = getmsgfac(word)) == NULL) { --------end of message.c--------- Here is the .shar file (from here to the end of the message): #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # config/os-type # config/mf.pyrOSx # config/os-pyrOSx.h # config/mf.dynix # config/os-dynix.h # config/os-dcosx.h # config/mf.dcosx # config/os-dynixptx.h # config/mf.dynixptx # missing/utimes.c # echo "x - extracting config/os-type (Text)" sed 's/^X//' << 'SHAR_EOF' > config/os-type && X#!/bin/sh X# X# Copyright (c) 1989 Jan-Simon Pendry X# Copyright (c) 1989 Imperial College of Science, Technology & Medicine X# Copyright (c) 1989 The Regents of the University of California. X# All rights reserved. X# X# This code is derived from software contributed to Berkeley by X# Jan-Simon Pendry at Imperial College, London. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# %W% (Berkeley) %G% X# X# $Id: os-type,v 1.1 1993/02/17 04:02:46 dbeusee Exp dbeusee $ X# X X# X# Take a pot-shot at your os type X# X X# X# First try poking around in /etc/motd X# X Xcase "`exec 2>/dev/null; head -2 /etc/motd`" in X*"Sun UNIX 4.2 Release 3."*) OS=sunos3;; X*"SunOS Release 4."*) OS=sunos4;; X*"SunOS 5."*) OS=sunos5;; X*"HP-UX on the HP"*) OS=hpux;; X*"DYNIX(R)"*) OS=dynix;; X*"DYNIX/ptx"*) OS=dynixptx;; X*" dcosx "*) OS=dcosx;; X*"Ultrix V2."*) OS=ultrix2_2;; X*"Ultrix V3."*) OS=ultrix3_0;; X*"Ultrix-32 V3."*) OS=ultrix3_0;; X*"Ultrix Worksystem V2."*) OS=ultrix3_0;; X*"ULTRIX V4.2"*) OS=ultrix4;; X*"ULTRIX V4."*) OS=ultrix4;; X*"HLH OTS Version 1."*) OS=hlh42;; X*"RISC iX release 1."*) OS=riscix;; X*"FPX 4."*) OS=fpx4;; X*"HCX/UX"*) OS=hcx;; X*"4.4 BSD UNIX"*) OS=bsd44;; X*"4.3 BSD Reno UNIX"*) OS=bsd44;; X*"4.3 BSD UNIX"*) if [ -f /etc/minidisk ]; then X OS=acis43 X elif [ -f /sbin/nfsiod ]; then X OS=bsd44 # prototype X else X OS=xinu43 X fi;; X*"Alliant Concentrix"*) OS=concen;; X*"Umax 4.3"*) OS=umax43;; X*) X# X# Well, that didn't work so apply some heuristics X# to the filesystem name space... X# X# echo "# ... inspecting File system ..." >&2 X if [ -f /etc/comply ]; then X OS=utek X elif [ -d /usr/lib/methods -o -d /etc/methods ]; then X OS=aix3 X elif [ -f /usr/bin/cat ]; then X OS=sos4 X elif [ -f /etc/nd ]; then X OS=sos3 X elif [ -f /etc/elcsd ]; then X echo "# ... Ultrix - assuming U4.0 ..." >&2 X OS=u4_0 X elif [ -f /hp-ux ]; then X OS=hpux X elif [ -f /etc/ttylocal ]; then X OS=xinu43 X elif [ -f /etc/minidisk ]; then X OS=acis43 X elif [ -f /etc/toolboxdaemon ]; then X OS=aux X elif [ -f /sbin/nfsiod ]; then X OS=bsd44 X elif [ -d /vrm ]; then X OS=aix2 X elif [ -f /dynix ]; then X OS=dynix X elif [ -f /bin/pyr ] && /bin/pyr; then X OS=pyrOSx X elif [ -d /NextApps ]; then X OS=next X elif [ -f /etc/gl/ucode ]; then X OS=irix3 X elif [ -f /usr/gfx/ucode ]; then X OS=irix4 X elif [ -f /stellix ]; then X OS=stellix X else X case "`(sh ../config/arch)2>/dev/null`" in X ibm032) OS=acis43;; X aviion) OS=dgux;; X *) OS=unknown;; X esac X fi;; Xesac X Xecho "" >&2 Xecho " OS appears to be \"${OS}\"" >&2 Xecho "" >&2 Xecho "${OS}" Xexit 0 SHAR_EOF chmod 0755 config/os-type || echo "restore of config/os-type fails" echo "x - extracting config/mf.pyrOSx (Text)" sed 's/^X//' << 'SHAR_EOF' > config/mf.pyrOSx && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.TEMPLATE,v 6.1 1993/01/07 02:44:08 mcooper Exp $ X# X X# X# pyrosx Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strerror.o X X# X# System libraries that we need to load. X# X#LIB_OS = -lPW SHAR_EOF chmod 0644 config/mf.pyrOSx || echo "restore of config/mf.pyrOSx fails" echo "x - extracting config/os-pyrOSx.h (Text)" sed 's/^X//' << 'SHAR_EOF' > config/os-pyrOSx.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-TEMPLATE.h,v 1.1 1993/02/16 02:13:11 mcooper Exp $ X * @(#)os-TEMPLATE.h X */ X X/* X * TEMPLATE os-*.h file X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(pyrOSx) X#define pyrOSx X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X#undef SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRECT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAIT3 X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE union wait X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_AOUT X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_BSD X X/* X * Type of arg functions we have. X */ X#undef ARG_TYPE X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef gid_t CHOWN_GID_T; X X/* X * Our types, usually these are uid_t and gid_t. X */ Xtypedef long UID_T; /* Must be signed */ Xtypedef long GID_T; /* Must be signed */ X X#define strchr index X#define strrchr rindex SHAR_EOF chmod 0444 config/os-pyrOSx.h || echo "restore of config/os-pyrOSx.h fails" echo "x - extracting config/mf.dynix (Text)" sed 's/^X//' << 'SHAR_EOF' > config/mf.dynix && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.dynix,v 6.1 1993/01/07 02:44:08 mcooper Exp $ X# X X# X# dynix Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strerror.o $(O)strdup.o X X# X# System libraries that we need to load. X# XLIB_SYS = -lseq -lc /usr/att/lib/libc.a X# SHAR_EOF chmod 0644 config/mf.dynix || echo "restore of config/mf.dynix fails" echo "x - extracting config/os-dynix.h (Text)" sed 's/^X//' << 'SHAR_EOF' > config/os-dynix.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-dynix.h,v 1.1 1993/02/16 02:13:11 mcooper Exp $ X * @(#)os-dynix.h X */ X X/* X * os-dynix.h file X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(dynix) X#define dynix X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X#undef SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRECT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAIT3 X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE union wait X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_AOUT X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_BSD X X/* X * Type of arg functions we have. X */ X#undef ARG_TYPE X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef gid_t CHOWN_GID_T; X X/* X * Our types, usually these are uid_t and gid_t. X */ Xtypedef long UID_T; /* Must be signed */ Xtypedef long GID_T; /* Must be signed */ X X#define strchr index X#define strrchr rindex SHAR_EOF chmod 0444 config/os-dynix.h || echo "restore of config/os-dynix.h fails" echo "x - extracting config/os-dcosx.h (Text)" sed 's/^X//' << 'SHAR_EOF' > config/os-dcosx.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-dcosx.h,v 6.1 1993/02/15 23:49:29 mcooper Exp mcooper $ X * @(#)os-dcosx.h X */ X X/* X * System V Release 4 (dcosx) X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(dcosx) X#define dcosx X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRENT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT2 X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAITPID X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE int X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_ELF X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_SYSV X X/* X * Type of arg functions we have. X */ X#define ARG_TYPE ARG_STDARG X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * Type of signal handling functions. X */ X#if !defined(POSIX_SIGNALS) X#define POSIX_SIGNALS X#endif X#include X#define signal(s,a) sigset(s,(void(*)())a) X X/* X * System V compatibility X */ X#include X#include X#include X#include X X#define bcopy(a,b,c) memcpy(b,a,c) X#define bzero(a,b) memset(a,0,b) X#define setlinebuf(a) setvbuf(a, NULL, _IOLBF, BUFSIZ) X X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef gid_t CHOWN_GID_T; X X/* X * Our types X */ Xtypedef uid_t UID_T; /* Must be signed */ Xtypedef gid_t GID_T; /* Must be signed */ X X/* dc/osx does not have this routine. Since it is only used to check for X * read-only mounted filesystems, we disable this functionality. So rdist X * will think all mounted filesystems are read-write. X */ Xstatic char * Xhasmntopt(mnt, opt) Xstruct mntent *mnt; Xchar *opt; X{ X return(0); X} SHAR_EOF chmod 0644 config/os-dcosx.h || echo "restore of config/os-dcosx.h fails" echo "x - extracting config/mf.dcosx (Text)" sed 's/^X//' << 'SHAR_EOF' > config/mf.dcosx && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.dcosx,v 6.1 1993/01/07 02:44:39 mcooper Exp mcooper $ X# X X# X# dcosx Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strcasecmp.o $(O)regex.o $(O)strtol.o X X# X# System libraries that we need to load. X# XLIB_SYS = -lnsl -lsocket -lc /usr/ucblib/libucb.a X X# X# No ranlib X# XRANLIB = SHAR_EOF chmod 0644 config/mf.dcosx || echo "restore of config/mf.dcosx fails" echo "x - extracting config/os-dynixptx.h (Text)" sed 's/^X//' << 'SHAR_EOF' > config/os-dynixptx.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-dynixptx.h,v 6.1 1993/02/15 23:49:29 mcooper Exp mcooper $ X * @(#)os-dynixptx.h X */ X X/* X * System V Release 4 (dynixptx) X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(dynixptx) X#define dynixptx X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRENT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAITPID X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE int X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_COFF X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_SYSV X X/* X * Type of arg functions we have. X */ X#define ARG_TYPE ARG_VARARGS X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * Type of signal handling functions. X */ X#if !defined(POSIX_SIGNALS) X#define POSIX_SIGNALS X#endif X#include X#define signal(s,a) sigset(s,(void(*)())a) X X/* X * System V compatibility X */ X#include X#include X#include X#include X#include X/* X #include X*/ X X#define bcopy(a,b,c) memcpy(b,a,c) X#define bzero(a,b) memset(a,0,b) X#define setlinebuf(a) setvbuf(a, NULL, _IOLBF, BUFSIZ) X X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef gid_t CHOWN_GID_T; X X/* X * Our types X */ Xtypedef uid_t UID_T; /* Must be signed */ Xtypedef gid_t GID_T; /* Must be signed */ X X/* ptx does not have setreuid() until 2.0. X * we loose euid=0 once setuid() called, so we don't use that either X */ X#define setreuid(a1,a2) 0 X X#define MOUNTED MNTTABNAME X X#define fchown(fd,uid,gid) -1 X#define fchmod(fd,mode) -1 SHAR_EOF chmod 0644 config/os-dynixptx.h || echo "restore of config/os-dynixptx.h fails" echo "x - extracting config/mf.dynixptx (Text)" sed 's/^X//' << 'SHAR_EOF' > config/mf.dynixptx && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.dynixptx,v 6.1 1993/01/07 02:44:08 mcooper Exp $ X# X X# X# Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)regex.o $(O)strcasecmp.o $(O)utimes.o X X# X# System libraries that we need to load. X# XLIB_SYS = -linet -lnsl -lsocket -lrpc -lseq X# X# no ranlib XRANLIB = SHAR_EOF chmod 0644 config/mf.dynixptx || echo "restore of config/mf.dynixptx fails" echo "x - extracting missing/utimes.c (Text)" sed 's/^X//' << 'SHAR_EOF' > missing/utimes.c && X#include X#include X#include X Xutimes(path, tvp) X char *path; X struct timeval tvp[2]; X{ X struct utimbuf t; X t.actime=tvp[0].tv_sec; X t.modtime=tvp[1].tv_sec; X return(utime(path,&t)); X} SHAR_EOF chmod 0644 missing/utimes.c || echo "restore of missing/utimes.c fails" exit 0 From hofer@informatik.uni-muenchen.de Wed Feb 17 09:47:21 1993 Return-Path: Received: from zeus.cip.informatik.uni-muenchen.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12910; Wed, 17 Feb 93 09:47:21 PST Received: by zeus.cip.informatik.uni-muenchen.de id AA11125 (5.65c8/IDA-1.4.4 for rdist-dev@usc.edu); Wed, 17 Feb 1993 18:46:57 +0100 From: Robert Hofer Message-Id: <199302171746.AA11125@zeus.cip.informatik.uni-muenchen.de> Subject: Worse bug in rdist6 To: rdist-dev@usc.edu Date: Wed, 17 Feb 1993 18:46:56 +0100 (MSZ) Cc: knott@informatik.tu-muenchen.de X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 5444 Hallo, i think i found a bad bug in the rdist6.* distribution. If rdist tries to distribute a file with a name that contains non-ascii characters it stops and loses the connection. This happend at our site, because some people use "german-umlaute" with ISO-8859-1 coding for some filesnames. Without these files, all is ok. This bug is in all rdist6 distributions. The old rdist (>> Cmd = K (\113) Msg = "10 755 39 727461137 729968534 root sys iris" inti: response() start zeus: [readchild(inti, 9916, 3) write done] zeus: [readchild(inti, 9916, 3) got 183 bytes] inti: <<< Cmd =  (\005) Msg = "" inti: recieved ACK inti: >>> Cmd = = (\075) Msg = "/usr/local/lmu/DIR/IrisDPP/./Server800/" inti: >>> Cmd =  (\005) Msg = "" inti: response() start zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 167 bytes] inti: <<< Cmd =  (\005) Msg = "" inti: recieved ACK *inti: sendit(ä, 0) inti: except(/usr/local/lib/ä) inti: update(ä, 0, 4000ac94) *inti: >>> Cmd = Q (\121) Msg = "ä" zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 249 bytes] inti: local error: update: unexpected control record inti: Created notify temp file '/tmp/rdista09916' inti: update status ä (/usr/local/lib/ä) is 0 inti: >>> Cmd = E (\105) Msg = "" inti: response() start inti: local error: Lost connection to inti zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 46 bytes] inti: doarrow(4001c400, inti, 4001c190) start zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 44 bytes] inti: makeconn inti failed before; skipping zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 32 bytes] inti: updating of inti finished zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: waitup() select returned 1 activechildren = 1 zeus: [readchild(inti, 9916, 3) start] zeus: [readchild(inti, 9916, 3) got 109 bytes] inti: Created notify temp file '/tmp/rdista09916' inti: closeconn() called inti: >>> Cmd =  (\002) Msg = "" zeus: [readchild(inti, 9916, 3) write done] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 2 zeus: readchild(inti, 9916, 3) at EOF zeus: waitup() end zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: waitup() select on 3 (inti) zeus: waitup() Call select(), activechildren=1 zeus: reap() called zeus: waitproc() nonblocking, active children = 1... zeus: Child process 9916 exited with status 2. zeus: waitproc() done (activechildren = 1) zeus: reap() pid = 9916 status = 0 activechildren=1 zeus: waitproc() nonblocking, active children = 1... zeus: waitproc() done (activechildren = 1) zeus: reap() pid = -1 status = 0 activechildren=1 zeus: reap() done zeus: waitup() select returned -1 activechildren = 1 zeus: Waiting for 1 children to finish. zeus: waitup() start zeus: childscan() start zeus: [readchild(inti, 9916, 3) start] zeus: readchild(inti, 9916, 3) done: amt = 0 errno = 4 zeus: readchild(inti, 9916, 3) at EOF zeus: removechild(inti, 9916, 3) start zeus: removechild() end zeus: childscan() end From dbeusee@us.oracle.com Thu Feb 18 04:05:17 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18943; Thu, 18 Feb 93 04:05:17 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA03076; Thu, 18 Feb 93 04:05:06 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28350; Thu, 18 Feb 93 03:58:29 PST Message-Id: <9302181158.AA28350@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 03:58:29 PST From: Don Beusee To: mcooper@usc.edu Subject: small enhancement patch Cc: rdist-dev@usc.edu Right now you can have just $FILE in the "special" clause. I added: $RFILE (remote filename ($FILE is local filename)) $BFILE (like `basename $FILE`) $BRFILE (like `basename $RFILE`) I also export FILE, RFILE, BFILE, and BRFILE into the environment before calling the command specified by the "special" clause. This allows the command to call a script, and the script has access to these variables. Here is the .shar file containing the patches for src/client.c and include/defs.h. The files are from diff -c output: #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.defs.h # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.1 1993/02/16 17:31:06 X--- src/client.c 1993/02/18 10:18:17 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 1.1 1993/02/16 17:31:06 dbeusee Exp dbeusee $"; X X static char sccsid[] = "@(#)client.c"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 6.43 1993/02/16 01:10:29 mcooper Exp mcooper $"; X X static char sccsid[] = "@(#)client.c"; X X*************** X*** 67,75 **** X static int sendit(); X X /* X * Return true if name is in the list. X */ X! int inlist(list, file) X struct namelist *list; X char *file; X { X--- 67,123 ---- X static int sendit(); X X /* X+ * return basename of file X+ */ X+ char * X+ basename(file) X+ char *file; X+ { X+ char *p; X+ if ((p=strrchr(file,'/')) != NULL) X+ return(p+1); X+ return(file); X+ } X+ X+ /* X+ * return remote file pathname (relative from target) X+ */ X+ char * X+ remfilename(src, dest, path) X+ char *src, *dest, *path; X+ { X+ static char *lname, *cp, buff[BUFSIZ]; X+ X+ debugmsg(DM_MISC, "remfilename: src=%s, dest=%s, path=%s\n", X+ src, dest, path); X+ if (path && *path) { X+ lname = strrchr(path, '/'); X+ if (lname == NULL || (strchr(src, '/') == NULL)) X+ lname = path; X+ else { X+ lname = cp = buff; X+ strcpy(cp, dest); X+ cp += strlen(cp); X+ while (*src) { X+ if (*path != *src) X+ break; X+ path++; src++; X+ } X+ strcat(cp, path); X+ } X+ } else { X+ lname = buff; X+ strcpy(lname, dest); X+ } X+ debugmsg(DM_MISC, "remfilename: remote filename=%s\n", lname); X+ return(lname); X+ } X+ X+ /* X * Return true if name is in the list. X */ X! int X! inlist(list, file) X struct namelist *list; X char *file; X { X*************** X*** 84,95 **** X /* X * Run any special commands for this file X */ X! static void runspecial(starget, opts) X char *starget; X int opts; X { X register struct subcmd *sc; X extern struct subcmd *subcmds; X X for (sc = subcmds; sc != NULL; sc = sc->sc_next) { X if (sc->sc_type != SPECIAL) X--- 132,147 ---- X /* X * Run any special commands for this file X */ X! static void X! runspecial(starget, opts) X char *starget; X int opts; X { X register struct subcmd *sc; X extern struct subcmd *subcmds; X+ char *rfile; X+ X+ rfile = remfilename(source, target, Tdest); X X for (sc = subcmds; sc != NULL; sc = sc->sc_next) { X if (sc->sc_type != SPECIAL) X*************** X*** 99,106 **** X message(MT_CHANGE, "special \"%s\"", sc->sc_name); X if (IS_ON(opts, DO_VERIFY)) X continue; X! (void) sendcmd(C_SPECIAL, "%s=%s;%s", X! E_SFILE, starget, sc->sc_name); X while (response() > 0) X ; X } X--- 151,164 ---- X message(MT_CHANGE, "special \"%s\"", sc->sc_name); X if (IS_ON(opts, DO_VERIFY)) X continue; X! (void) sendcmd(C_SPECIAL, X! "%s=%s;%s=%s;%s=%s;%s=%s;export %s %s %s %s;%s", X! E_SFILE, starget, X! E_SRFILE, rfile, X! E_SBFILE, basename(starget), X! E_SBRFILE, basename(rfile), X! E_SFILE, E_SRFILE, E_SBFILE, E_SBRFILE, X! sc->sc_name); X while (response() > 0) X ; X } X*************** X*** 109,115 **** X /* X * Run commands for an entire cmd X */ X! extern void runcmdspecial(cmd, filev) X struct cmd *cmd; X char **filev; X { X--- 167,174 ---- X /* X * Run commands for an entire cmd X */ X! extern void X! runcmdspecial(cmd, filev) X struct cmd *cmd; X char **filev; X { X*************** X*** 163,169 **** X /* X * Save and retrieve hard link info X */ X! static struct linkbuf *linkinfo(statp) X struct stat *statp; X { X struct linkbuf *lp; X--- 222,229 ---- X /* X * Save and retrieve hard link info X */ X! static struct linkbuf * X! linkinfo(statp) X struct stat *statp; X { X struct linkbuf *lp; X*************** X*** 193,199 **** X /* X * Send a hardlink X */ X! static int sendhardlink(opts, lp, rname) X int opts; X struct linkbuf *lp; X char *rname; X--- 253,260 ---- X /* X * Send a hardlink X */ X! static int X! sendhardlink(opts, lp, rname) X int opts; X struct linkbuf *lp; X char *rname; X*************** X*** 215,236 **** X while (*lname == '/') X lname++; X } else { X! lname = strrchr(lp->pathname, '/'); X! if (lname == NULL) X! lname = lp->pathname; X! else { X! lname = cp = buff; X! path = lp->pathname; X! strcpy(cp, lp->target); X! cp += strlen(cp); X! src = lp->src; X! while (*src) { X! if (*path != *src) X! break; X! *path++ = *src++; X! } X! strcat(cp, path); X! } X } X debugmsg(DM_MISC, "sendhardlink: lname=%s\n", lname); X (void) sendcmd(C_RECVHARDLINK, "%o %s %s", X--- 276,284 ---- X while (*lname == '/') X lname++; X } else { X! lname = buff; X! strcpy(lname, remfilename(lp->src, X! lp->target, lp->pathname)); X } X debugmsg(DM_MISC, "sendhardlink: lname=%s\n", lname); X (void) sendcmd(C_RECVHARDLINK, "%o %s %s", X*************** X*** 243,249 **** X /* X * Send a file X */ X! static int sendfile(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X--- 291,298 ---- X /* X * Send a file X */ X! static int X! sendfile(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X*************** X*** 325,331 **** X * Check for files on the machine being updated that are not on the master X * machine and remove them. X */ X! static void rmchk(opts) X int opts; X { X register char *s; X--- 374,381 ---- X * Check for files on the machine being updated that are not on the master X * machine and remove them. X */ X! static void X! rmchk(opts) X int opts; X { X register char *s; X*************** X*** 393,399 **** X /* X * Send a directory X */ X! static int senddir(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X--- 443,450 ---- X /* X * Send a directory X */ X! static int X! senddir(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X*************** X*** 461,467 **** X /* X * Send a link X */ X! static int sendlink(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X--- 512,519 ---- X /* X * Send a link X */ X! static int X! sendlink(rname, opts, stb, user, group) X char *rname; X int opts; X struct stat *stb; X*************** X*** 578,584 **** X * US_DOCOMP - comparing binaries to determine if out of date X * US_MODE - File modes do not match X */ X! static int update(rname, opts, statp) X char *rname; X int opts; X struct stat *statp; X--- 630,637 ---- X * US_DOCOMP - comparing binaries to determine if out of date X * US_MODE - File modes do not match X */ X! static int X! update(rname, opts, statp) X char *rname; X int opts; X struct stat *statp; X*************** X*** 813,819 **** X /* X * Stat a file X */ X! static int dostat(file, statbuf, opts) X char *file; X struct stat *statbuf; X int opts; X--- 866,873 ---- X /* X * Stat a file X */ X! static int X! dostat(file, statbuf, opts) X char *file; X struct stat *statbuf; X int opts; X*************** X*** 840,846 **** X * Return 0 if nothing happened. X * Return > 0 if anything is updated. X */ X! static int sendit(rname, opts) X char *rname; X int opts; X { X--- 894,901 ---- X * Return 0 if nothing happened. X * Return > 0 if anything is updated. X */ X! static int X! sendit(rname, opts) X char *rname; X int opts; X { X*************** X*** 957,963 **** X /* X * Remove temporary files and do any cleanup operations before exiting. X */ X! extern void cleanup() X { X char *file; X #ifdef USE_STATDB X--- 1012,1019 ---- X /* X * Remove temporary files and do any cleanup operations before exiting. X */ X! extern void X! cleanup() X { X char *file; X #ifdef USE_STATDB X*************** X*** 979,985 **** X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int install(src, dest, destdir, opts) X char *src, *dest; X int destdir, opts; X { X--- 1035,1042 ---- X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int X! install(src, dest, destdir, opts) X char *src, *dest; X int destdir, opts; X { X*************** X*** 987,992 **** X--- 1044,1054 ---- X char *rname; X int didupdate = 0; X X+ /* X+ * Save source name X+ */ X+ (void) strcpy(source, src); X+ X if (dest == NULL) { X FLAG_OFF(opts, DO_WHOLE); /* WHOLE only useful if renaming */ X dest = src; X*************** X*** 1030,1036 **** X rname++; X } X X! debugmsg(DM_MISC, "target=%s src=%s rname=%s dest='%s' destdir=%d\n", X target, source, rname, dest, destdir); X X /* X--- 1092,1099 ---- X rname++; X } X X! debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d\n", X target, source, rname, dest, destdir); X X /* X*************** X*** 1054,1067 **** X Tdest = destcopy; X } X X- /* X- * Save source name X- */ X- (void) strcpy(source, src); X- X didupdate = sendit(rname, opts); X Tdest = 0; X X return(didupdate); X } X- X--- 1117,1124 ---- SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.defs.h && X*** 1.1 1993/02/17 13:02:26 X--- include/defs.h 1993/02/18 09:40:10 X*************** X*** 228,234 **** X * Environment variable names X */ X #define E_FILES "FILES" X! #define E_SFILE "FILE" X X /* X * Suffix to use when saving files X--- 228,237 ---- X * Environment variable names X */ X #define E_FILES "FILES" X! #define E_SFILE "FILE" /* local filenmae */ X! #define E_SRFILE "RFILE" /* Remove Filename */ X! #define E_SBFILE "BFILE" /* basename of FILE */ X! #define E_SBRFILE "BRFILE" /* basename of RFILE */ X X /* X * Suffix to use when saving files SHAR_EOF chmod 0644 patch.defs.h || echo "restore of patch.defs.h fails" exit 0 From dbeusee@us.oracle.com Thu Feb 18 06:00:57 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21808; Thu, 18 Feb 93 06:00:57 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA05647; Thu, 18 Feb 93 06:00:54 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28994; Thu, 18 Feb 93 05:54:17 PST Message-Id: <9302181354.AA28994@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 05:54:17 PST From: Don Beusee To: mcooper@usc.edu Subject: last patched messed up hardlink fix Cc: rdist-dev@usc.edu The patch I just sent out messed up the hardlink fix. Here is the patch to apply on top of that patch to fix the hardlink: Apply this to src/client.c: *** 1.2 1993/02/18 13:42:49 --- src/client.c 1993/02/18 13:45:04 *************** *** 92,98 **** src, dest, path); if (path && *path) { lname = strrchr(path, '/'); ! if (lname == NULL || (strchr(src, '/') == NULL)) lname = path; else { lname = cp = buff; --- 92,98 ---- src, dest, path); if (path && *path) { lname = strrchr(path, '/'); ! if (lname == NULL) lname = path; else { lname = cp = buff; ======================================================== Regards, Don. From rsalz@osf.org Thu Feb 18 06:03:11 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21853; Thu, 18 Feb 93 06:03:11 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA18881; Thu, 18 Feb 93 09:03:06 -0500 Received: by earth.osf.org (5.65/4.7) id AA03517; Thu, 18 Feb 93 09:03:05 -0500 Date: Thu, 18 Feb 93 09:03:05 -0500 From: rsalz@osf.org Message-Id: <9302181403.AA03517@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Those names, RFILE, BFILE, BRFILE, are horrible. Why be needlessly terse and obscure? From dbeusee@us.oracle.com Thu Feb 18 06:32:04 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22968; Thu, 18 Feb 93 06:32:04 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA06606; Thu, 18 Feb 93 06:31:53 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29073; Thu, 18 Feb 93 06:25:17 PST Message-Id: <9302181425.AA29073@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 06:25:17 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu They are not the greatest, but I wanted to follow the $FILE pattern and keep the names short. Do you have some better suggestions (with reasonably short names)? From rsalz@osf.org Thu Feb 18 05:57:43 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29007; Thu, 18 Feb 93 05:57:42 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA05782; Thu, 18 Feb 93 06:04:10 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA18881; Thu, 18 Feb 93 09:03:06 -0500 Received: by earth.osf.org (5.65/4.7) id AA03517; Thu, 18 Feb 93 09:03:05 -0500 Date: Thu, 18 Feb 93 09:03:05 -0500 From: rsalz@osf.org Message-Id: <9302181403.AA03517@earth.osf.org> To: dbeusee@us, mcooper@usc.edu Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R Those names, RFILE, BFILE, BRFILE, are horrible. Why be needlessly terse and obscure? From rsalz@osf.org Thu Feb 18 06:38:06 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23187; Thu, 18 Feb 93 06:38:06 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA21320; Thu, 18 Feb 93 09:38:04 -0500 Received: by earth.osf.org (5.65/4.7) id AA03603; Thu, 18 Feb 93 09:38:02 -0500 Date: Thu, 18 Feb 93 09:38:02 -0500 From: rsalz@osf.org Message-Id: <9302181438.AA03603@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu > Do you have some better suggestions (with reasonably short names)? Off the top of my head: REMOTEFILE or REMFILE BASEFILENAME or BASENAME or BASEFILE REMOTEBASENAME or REMBASENAME or REMBASEFILE etc How often are these names used that you really care about a five or 10-char difference? /r$ From dbeusee@us.oracle.com Thu Feb 18 07:10:26 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24371; Thu, 18 Feb 93 07:10:26 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA07611; Thu, 18 Feb 93 07:10:19 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29144; Thu, 18 Feb 93 07:03:43 PST Message-Id: <9302181503.AA29144@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 07:03:43 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu It isn't so much how often the names are used, its to make it possible for a "special" command to fit on one line (yeah, I know it is not a requirement - just taste). Take this example: myfile.ptx -> myhost install /usr/local/bin/myfile; special "cd /usr/local/bin; rm -f $BRFILE; ln -s $BRFILE.ptx $BRFILE"; Obviously it can get ugly when the command wraps to the next line. Mike, what do you think? Should we: rename $RFILE to $REMOTEFILE rename $BFILE to $BASEFILE rename $BRFILE to $BASEREMFILE Also, I did not update the man pages for these new variables - can you do that when you get time? Does the shell have any limitations on the length of the variable on any platform? Regards, Don. From rsalz@osf.org Thu Feb 18 06:32:28 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29087; Thu, 18 Feb 93 06:32:26 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA06790; Thu, 18 Feb 93 06:38:53 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA21320; Thu, 18 Feb 93 09:38:04 -0500 Received: by earth.osf.org (5.65/4.7) id AA03603; Thu, 18 Feb 93 09:38:02 -0500 Date: Thu, 18 Feb 93 09:38:02 -0500 From: rsalz@osf.org Message-Id: <9302181438.AA03603@earth.osf.org> To: dbeusee@us, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R > Do you have some better suggestions (with reasonably short names)? Off the top of my head: REMOTEFILE or REMFILE BASEFILENAME or BASENAME or BASEFILE REMOTEBASENAME or REMBASENAME or REMBASEFILE etc How often are these names used that you really care about a five or 10-char difference? /r$ From rsalz@osf.org Thu Feb 18 07:28:32 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24770; Thu, 18 Feb 93 07:28:32 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24332; Thu, 18 Feb 93 10:20:02 -0500 Received: by earth.osf.org (5.65/4.7) id AA03693; Thu, 18 Feb 93 10:20:00 -0500 Date: Thu, 18 Feb 93 10:20:00 -0500 From: rsalz@osf.org Message-Id: <9302181520.AA03693@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu >Obviously it can get ugly when the command wraps to the next line. Does rdist handle backslash-return "the right way" in quoted strings? If not, it probably should: special "cd /usr/local/bin; \ rm -f $BASEREMFILE; \ ln -s $BASEREMFILE.ptx $BASEREMFILE"; Note that this can be written with only one special var if you use the "basename" command: special "cd /usr/local/bin; \ B=`basename $REMFILE`; \ rm -f $$B; \ ln -s $$B.ptx $$B"; From wls@astro.UMD.EDU Thu Feb 18 07:29:20 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24797; Thu, 18 Feb 93 07:29:20 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA14689; Thu, 18 Feb 1993 10:29:20 -0500 Date: Thu, 18 Feb 1993 10:29:20 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181529.AA14689@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: small enhancement patch I would like to cast my vote for the shorter of the names. Actually, I think that the names used for FILE or BFILE should be the remote name rather than the name at the master. Of what use on the remote host is the name of the file on the master? Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From tchrist@pixel.convex.com Thu Feb 18 07:36:03 1993 Return-Path: Received: from convex.convex.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24983; Thu, 18 Feb 93 07:36:03 PST Received: from pixel.convex.com by convex.convex.com (5.64/1.35) id AA15774; Thu, 18 Feb 93 09:35:55 -0600 Received: from localhost by pixel.convex.com (5.64/1.28) id AA05503; Thu, 18 Feb 93 09:35:51 -0600 To: rsalz@osf.org Cc: dbeusee@us.oracle.com, mcooper@usc.edu, rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: rsalz@osf.org's message <9302181520.AA03693@earth.osf.org> of Thu, 18 Feb 93 10:20:00 EST. References: <9302181520.AA03693@earth.osf.org> Reply-To: tchrist@convex.com Date: Thu, 18 Feb 93 08:35:51 CST Message-Id: <5498.730049751@pixel.convex.com> From: Tom Christiansen > >Obviously it can get ugly when the command wraps to the next line. > Does rdist handle backslash-return "the right way" in quoted strings? > If not, it probably should: > special "cd /usr/local/bin; \ > rm -f $BASEREMFILE; \ > ln -s $BASEREMFILE.ptx $BASEREMFILE"; > Note that this can be written with only one special var if you use > the "basename" command: > special "cd /usr/local/bin; \ > B=`basename $REMFILE`; \ > rm -f $$B; \ > ln -s $$B.ptx $$B"; Yes, it does do what you want, but happily it also does what I want and considers the backslash superfluous. This works equally well and is more legible: special "cd /usr/local/bin; rm -f $BASEREMFILE; ln -s $BASEREMFILE.ptx $BASEREMFILE"; The fewer backslashes, the better. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist The hardest thing in the world to understand is the income tax. --Albert Einstein From wls@astro.UMD.EDU Thu Feb 18 07:47:17 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25390; Thu, 18 Feb 93 07:47:17 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA14871; Thu, 18 Feb 1993 10:47:17 -0500 Date: Thu, 18 Feb 1993 10:47:17 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181547.AA14871@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: local verses remote host names This brings up another issue. The messages printed out when a file is removed, installed or updated. Presently the path name on the master host is given when a file is installed or updated but the remote path name is given when the file is removed. For consistency I think it should be the same in all three cases. I think that it is much less confusing if the pathname given always be the remote name. After all, to use an example from last nights log after I had installed the new rdist, the message draco: /usr/ucb/rdist: updating is less confusing than draco: /export/exec/sun3/ucb/rdist: updating since it is /usr/ucb/rdist, not /export/exec/sun3/ucb/rdist that got updated on draco. I have been intending to suggest a patch for this (and indeed had so patched the old 4.3 BSD rdist) but had not got around to it. However the current discussion about local verses remote names has made me want to bring this up. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From neal@ctd.comsat.com Thu Feb 18 07:54:47 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25579; Thu, 18 Feb 93 07:54:47 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nPDaB-0003TdC; Thu, 18 Feb 93 10:54 EST Message-Id: Date: Thu, 18 Feb 93 10:54 EST From: neal@ctd.comsat.com (Neal Becker) To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: local verses remote host names In-Reply-To: <199302181547.AA14871@lynx.astro.umd.edu> References: <199302181547.AA14871@lynx.astro.umd.edu> I'd like to see a little more information here also. If remote and local names differ why not give both? master:/export/exec/sun3/ucb/rdist -> draco:/usr/ucb/rdist updating >>>>> On Thu, 18 Feb 1993 10:47:17 -0500, wls@astro.UMD.EDU (William L. Sebok) said: William> This brings up another issue. The messages printed out when a file is removed, William> installed or updated. Presently the path name on the master host is given William> when a file is installed or updated but the remote path name is given when William> the file is removed. For consistency I think it should be the same in all William> three cases. I think that it is much less confusing if the pathname given William> always be the remote name. After all, to use an example from last nights log William> after I had installed the new rdist, the message William> draco: /usr/ucb/rdist: updating William> is less confusing than William> draco: /export/exec/sun3/ucb/rdist: updating William> since it is /usr/ucb/rdist, not /export/exec/sun3/ucb/rdist that got updated William> on draco. William> I have been intending to suggest a patch for this (and indeed had so patched William> the old 4.3 BSD rdist) but had not got around to it. However the current William> discussion about local verses remote names has made me want to bring this up. William> Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu Message: I care. -- President George Bush, in New Hampshire. From wls@astro.UMD.EDU Thu Feb 18 08:30:07 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26563; Thu, 18 Feb 93 08:30:07 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA15334; Thu, 18 Feb 1993 11:30:07 -0500 Date: Thu, 18 Feb 1993 11:30:07 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181630.AA15334@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: machine specific compile options In the new fancy scheme of things, one is supposed to give one's makefile changes in Makefile.local. However what if one wants to give changes that are specific to a particular architecture: for example, compiling with "gcc -O2" on suns and "cc -O" on another machine. Once can hack config/mf.YOUR_OS but one really isn't supposed to do that. The following patch allows local Makefiles of the form: Makefile.local.YOUR_OS (for example Makefile.local.sunos4) to exist and to override definitions given in Makefile.local. ---Cut Here--- *** mf/Makefile.top.ORIG Wed Jan 6 21:59:07 1993 --- mf/Makefile.top Tue Feb 16 14:22:21 1993 *************** *** 58,63 **** --- 58,66 ---- if [ -f ../Makefile.local ]; then \ MKARGS="$${MKARGS} -f ../Makefile.local"; \ fi; \ + if [ -f ../Makefile.local."$${OS}" ]; then \ + MKARGS="$${MKARGS} -f ../Makefile.local.$${OS}"; \ + fi; \ if [ -f ../config/mf.$${OS} ]; then \ MKARGS="$${MKARGS} -f ../config/mf.$${OS}"; \ fi; \ ---Cut Here--- Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Thu Feb 18 08:43:26 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26809; Thu, 18 Feb 93 08:43:26 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA15522; Thu, 18 Feb 1993 11:43:25 -0500 Date: Thu, 18 Feb 1993 11:43:25 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181643.AA15522@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Port of new rdist to multiflow Here is the stuff to port rdist-6.1.0 to the Multiflow. The multiflow's make doesn't automatically define the variable MAKE. Therefore the support/Makefile and doc/Makefile fail. I changed them to be like the other makefiles. There was also a problem that had my hair tearing out. It appears that the Multiflow's Bourne shell called by a Makefile will exit if a command returns non-zero (i.e. "bad") status, even if the command is after an "if". This made all of the tests in mf/Makefile.top completely hopeless. I solved that problem by giving up on the Multiflow's Bourne shell and replacing it with a more modern one. First come the patches: --- Cut HERE--- *** config/os-type.ORIG Tue Jan 5 17:52:31 1993 --- config/os-type Tue Feb 16 12:13:54 1993 *************** *** 75,80 **** --- 75,81 ---- fi;; *"Alliant Concentrix"*) OS=concen;; *"Umax 4.3"*) OS=umax43;; + *"Multiflow 4.3 BSD"*) OS=tracebsd;; *) # # Well, that didn't work so apply some heuristics *** doc/Makefile.ORIG Wed Jan 6 21:58:45 1993 --- doc/Makefile Wed Feb 17 14:35:36 1993 *************** *** 34,44 **** # $Id: Makefile,v 6.2 1993/01/07 02:58:40 mcooper Exp mcooper $ # MKARG = -f ../mf/Makefile.top TARGET=doc all: doc doc clean install install.man: FRC ! @${MAKE} ${MKARG} $@ FRC: --- 34,46 ---- # $Id: Makefile,v 6.2 1993/01/07 02:58:40 mcooper Exp mcooper $ # + Make = make + MAK = ${Make} Make="${Make}" MKARG = -f ../mf/Makefile.top TARGET=doc all: doc doc clean install install.man: FRC ! @${MAK} ${MKARG} $@ FRC: *** support/Makefile.ORIG Wed Feb 17 14:37:01 1993 --- support/Makefile Wed Feb 17 14:36:39 1993 *************** *** 33,43 **** # # $Id: Makefile,v 6.2 1993/01/07 02:58:49 mcooper Exp mcooper $ # MKARG = -f ../mf/Makefile.top TARGET=support all: support support clean install install.man: FRC ! @${MAKE} ${MKARG} $@ FRC: --- 33,45 ---- # # $Id: Makefile,v 6.2 1993/01/07 02:58:49 mcooper Exp mcooper $ # + Make = make + MAK = ${Make} Make="${Make}" MKARG = -f ../mf/Makefile.top TARGET=support all: support support clean install install.man: FRC ! @${MAK} ${MKARG} $@ FRC: --- End Cut HERE--- Then come the files to be installed in config/ --- Cut HERE and extract with sh --- #! /bin/sh # This is a shell archive. Remove anything before this line, then feed it # into a shell via "sh file" or similar. To overwrite existing files, # type "sh file -c". # The tool that generated this appeared in the comp.sources.unix newsgroup; # send mail to comp-sources-unix@uunet.uu.net if you want that tool. # Contents: mf.tracebsd os-tracebsd.h # Wrapped by wls@lynx on Thu Feb 18 11:32:36 1993 PATH=/bin:/usr/bin:/usr/ucb ; export PATH echo If this archive is complete, you will see the following message: echo ' "shar: End of archive."' if test -f 'mf.tracebsd' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'mf.tracebsd'\" else echo shar: Extracting \"'mf.tracebsd'\" \(2151 characters\) sed "s/^X//" >'mf.tracebsd' <<'END_OF_FILE' X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.TRACEBSD,v 6.1 1993/01/07 02:44:08 mcooper Exp $ X# X X# X# Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strerror.o $(O)strcasecmp.o $(O)strdup.o $(O)regex.o X X# X# System libraries that we need to load. X# X#LIB_OS = -lPW END_OF_FILE if test 2151 -ne `wc -c <'mf.tracebsd'`; then echo shar: \"'mf.tracebsd'\" unpacked with wrong size! fi # end of 'mf.tracebsd' fi if test -f 'os-tracebsd.h' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'os-tracebsd.h'\" else echo shar: Extracting \"'os-tracebsd.h'\" \(3328 characters\) sed "s/^X//" >'os-tracebsd.h' <<'END_OF_FILE' X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-TEMPLATE.h,v 1.1 1993/02/16 02:13:11 mcooper Exp $ X * @(#)os-TEMPLATE.h X */ X X/* X * TEMPLATE os-*.h file X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(TRACEBSD) X#define TRACEBSD X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRECT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAIT3 X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE union wait X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_AOUT X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_BSD X X/* X * Type of arg functions we have. X */ X#define ARG_TYPE ARG_VARARGS X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef int CHOWN_GID_T; X X/* X * Our types, usually these are uid_t and gid_t. X */ Xtypedef int UID_T; /* Must be signed */ Xtypedef int GID_T; /* Must be signed */ END_OF_FILE if test 3328 -ne `wc -c <'os-tracebsd.h'`; then echo shar: \"'os-tracebsd.h'\" unpacked with wrong size! fi # end of 'os-tracebsd.h' fi echo shar: End of archive. exit 0 --- End Cut HERE--- Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From rsalz@osf.org Thu Feb 18 09:10:14 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27737; Thu, 18 Feb 93 09:10:14 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA02601; Thu, 18 Feb 93 12:10:12 -0500 Received: by earth.osf.org (5.65/4.7) id AA03941; Thu, 18 Feb 93 12:10:10 -0500 Date: Thu, 18 Feb 93 12:10:10 -0500 From: rsalz@osf.org Message-Id: <9302181710.AA03941@earth.osf.org> To: rdist-dev@usc.edu, wls@astro.UMD.EDU Subject: Re: Port of new rdist to multiflow >Multiflow's Bourne shell called by a Makefile will exit if a command returns >non-zero (i.e. "bad") status, even if the command is after an "if". This is a problem for ANY Version 7 derived make, including those that come from 4.2BSD. It was a pain for me with INN; I had to use an external script. From pds@lemming.webo.dg.com Thu Feb 18 09:49:05 1993 Return-Path: Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29102; Thu, 18 Feb 93 09:49:05 PST Received: from lemming by dg-webo.webo.dg.com (5.4.1/dg-webo-v1) id AA18691; Thu, 18 Feb 1993 11:57:57 -0500 Received: by lemming.webo.dg.com (5.4.1/dg-s01) id AA18780; Thu, 18 Feb 1993 11:57:55 -0500 Date: Thu, 18 Feb 1993 11:57:55 -0500 From: pds@lemming.webo.dg.com (Paul D. Smith) Message-Id: <9302181657.AA18780@lemming.webo.dg.com> To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: machine specific compile options In-Reply-To: <199302181630.AA15334@lynx.astro.umd.edu> References: <199302181630.AA15334@lynx.astro.umd.edu> [] Regarding machine specific compile options; [] wls@astro.UMD.EDU (William L. Sebok) writes: wls> In the new fancy scheme of things, one is supposed to give wls> one's makefile changes in Makefile.local. However what if one wls> wants to give changes that are specific to a particular wls> architecture: for example, compiling with "gcc -O2" on suns and wls> "cc -O" on another machine. Once can hack config/mf.YOUR_OS wls> but one really isn't supposed to do that. Why not? As I understand it, config/mf.OS sets up makefiles for that OS in general, and Makefile.local is for site-specific modifications. I added the following stuff to the config/mf.dgux I sent in earlier this week: # # Use gcc, so that -c -o works; cc is basically "gcc -traditional", but # doesn't like -c -o. Note gcc is the bundled compiler on DG/UX # CC = gcc # # DG/UX doesn't need/have ranlib(1) # RANLIB = These are general overrides for all DG/UX systems, since all have gcc and none have ranlib. Site-specific mods, such as changes in pathnames, etc. certainly should go in Makefile.local. Or am I misunderstanding your question--are you talking about building rdist on multiple architectures from the same source directory? paul ----- ------------------------------------------------------------------ | Paul D. Smith | paul_smith@dg.com | | Data General Corp. | pds@lemming.webo.dg.com | | Network Systems Development Division | | | Open Network Systems Development | "Pretty Damn S..." | ------------------------------------------------------------------ From mcooper@ucs.usc.edu Thu Feb 18 09:58:22 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29411; Thu, 18 Feb 93 09:58:22 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00336; Thu, 18 Feb 93 09:58:21 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 9:58:20 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rsalz@osf.org Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: Your message of Thu, 18 Feb 93 09:03:05 -0500 Message-Id: How about REMFILE, BASEFILE, and BASEREMFILE? mike From mcooper@ucs.usc.edu Thu Feb 18 10:02:16 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29496; Thu, 18 Feb 93 10:02:16 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00368; Thu, 18 Feb 93 10:02:15 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 10:02:14 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: Your message of Thu, 18 Feb 1993 10:29:20 -0500 Message-Id: Changing the behavior of $FILE breaks backwards compatibility with Distfiles. I think it's safer to add a new variable that people can explicitly use. mike From wls@astro.UMD.EDU Thu Feb 18 10:01:03 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29466; Thu, 18 Feb 93 10:01:03 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA16200; Thu, 18 Feb 1993 13:01:03 -0500 Date: Thu, 18 Feb 1993 13:01:03 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181801.AA16200@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: machine specific compile options pds@lemming.webo.dg.com (Paul D. Smith) says: > ... As I understand it, config/mf.OS sets up makefiles for that OS > in general, and Makefile.local is for site-specific modifications. It might be site specific which compiler or which compiler option is used for a particular OS. > Site-specific mods, such as changes in pathnames, etc. certainly should > go in Makefile.local. Or am I misunderstanding your question--are you > talking about building rdist on multiple architectures from the same > source directory? Yes I am. Do it all of the time here, sometimes though when I want to do simultaneous compiles with different architectures on a different directory full of symbolic links back to the source directory. I don't feel that I should have to take up the space for multiple copies of the source, especially since this new scheme is supposed to be transparently portable. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Thu Feb 18 10:05:45 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29798; Thu, 18 Feb 93 10:05:45 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA16259; Thu, 18 Feb 1993 13:05:45 -0500 Date: Thu, 18 Feb 1993 13:05:45 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181805.AA16259@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: small enhancement patch > From: Michael A. Cooper > Changing the behavior of $FILE breaks backwards compatibility with Distfiles. > I think it's safer to add a new variable that people can explicitly use. True, but I never could figure out the use of the old behavior, except perhaps in some sort of logging. --- Bill From mcooper@ucs.usc.edu Thu Feb 18 10:04:45 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29716; Thu, 18 Feb 93 10:04:45 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00382; Thu, 18 Feb 93 10:04:44 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 10:04:43 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: local verses remote host names In-Reply-To: Your message of Thu, 18 Feb 1993 10:47:17 -0500 Message-Id: Yes, my todo list has had in it an item to change the default behavior of file name printing to be the name of the file on the remote host. An option would also make rdist print local file names. If you have the code, it'll make it into rdist faster .... :-) mike From mcooper@ucs.usc.edu Thu Feb 18 10:08:06 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29905; Thu, 18 Feb 93 10:08:06 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00407; Thu, 18 Feb 93 10:08:04 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 10:08:03 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: wls@astro.UMD.EDU (William L. Sebok), rdist-dev@usc.edu Subject: Re: local verses remote host names In-Reply-To: Your message of Thu, 18 Feb 93 10:54 EST Message-Id: That may be useful in some cases, but for long file names, it makes things difficult to read. This could probably be another option. mike From wls@astro.UMD.EDU Thu Feb 18 10:59:32 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02038; Thu, 18 Feb 93 10:59:32 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA17056; Thu, 18 Feb 1993 13:59:31 -0500 Date: Thu, 18 Feb 1993 13:59:31 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181859.AA17056@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: '&' set operator, yet another small addition The following patch implements the '&' operation as the "intersection" operator for set arithmetic. The intersection operation has often been found useful in maintlinks, my program that manages symbolic links. It can't really be constructed from the rdist '+' (union) operator nor from the '-' operator because there is no concept of set negation present. With it, for example, one can list the set of sun3's and list the set of computers that have local disks and then ask for the set of sun3's that have local disks. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu --Cut Here--- *** src/gram.y.ORIG Tue Jan 5 17:44:35 1993 --- src/gram.y Thu Feb 18 12:48:48 1993 *************** *** 53,59 **** #include "defs.h" ! static struct namelist *addnl(), *subnl(); struct cmd *cmds = NULL; struct cmd *last_cmd; struct namelist *last_n; --- 53,59 ---- #include "defs.h" ! static struct namelist *addnl(), *subnl(), *andnl(); struct cmd *cmds = NULL; struct cmd *last_cmd; struct namelist *last_n; *************** *** 119,124 **** --- 119,127 ---- | nlist '+' nlist { $$ = addnl($1, $3); } + | nlist '&' nlist { + $$ = andnl($1, $3); + } ; nlist: NAME = { *************** *** 255,260 **** --- 258,265 ---- case '(': /* LP */ case ')': /* RP */ case ';': /* SM */ + case '+': + case '&': return(c); case '-': /* -> */ *************** *** 264,272 **** c = '-'; break; - case '+': - return '+'; - case '"': /* STRING */ cp1 = yytext; cp2 = &yytext[INMAX - 1]; --- 269,274 ---- *************** *** 576,581 **** --- 578,603 ---- n2 = expand(n2, E_VARS); for (prev = NULL; n1; n1 = n1->n_next) if (!innl(n2, n1->n_name)) { + nl = makenl(n1->n_name); + nl->n_next = prev; + prev = nl; + } + return(prev); + } + + /* + * Copy all items of n1 that are also in n2. + */ + static struct namelist * + andnl(n1, n2) + struct namelist *n1, *n2; + { + struct namelist *nl, *prev; + + n1 = expand(n1, E_VARS); + n2 = expand(n2, E_VARS); + for (prev = NULL; n1; n1 = n1->n_next) + if (innl(n2, n1->n_name)) { nl = makenl(n1->n_name); nl->n_next = prev; prev = nl; *** doc/rdist.man.ORIG Mon Feb 15 18:43:16 1993 --- doc/rdist.man Thu Feb 18 13:41:52 1993 *************** *** 547,554 **** `(' `)' .fi ! These simple lists can be modified by using one level of set addition ! or subtraction like this: .nf .ti +.5i --- 547,554 ---- `(' `)' .fi ! These simple lists can be modified by using one level of set addition, ! subtraction, or intersection like this: .nf .ti +.5i *************** *** 556,561 **** --- 556,564 ---- or .ti +.5i list '+' list + or + .ti +.5i + list '&' list .fi If additional modifications are needed (e.g., ``all servers and client --Cut Here--- From wls@astro.UMD.EDU Thu Feb 18 11:53:50 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04307; Thu, 18 Feb 93 11:53:50 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA17617; Thu, 18 Feb 1993 14:53:50 -0500 Date: Thu, 18 Feb 1993 14:53:50 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181953.AA17617@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: list awkwardness The seems to be an awkwardness with the use of lists that get down to 1 or 0 elements. I came across this again when I was testing out the '&' option that I just posted but it has bitten me again in other forms in the past. The setup: I have two directories, /lynx/wls/play2 on machine lynx, and /a/wls/play2 on machine astro. First directory has a "Distfile" and 6 files named "1", "2", "3", "4", "5", and "6". The second directory is empty. The contents of the Distfile is initially: ================= a = ( 1 2 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= I get: astro: updating host astro astro: /lynx/wls/play2/2: installing astro: /lynx/wls/play2/1: installing astro: updating of astro finished So far so good, c should contain the set ( 1 2 ). Then I cleared out the the destination directory and changed the Distfile to: ================= a = ( 2 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= removing the 1st file. c should now contain ( 2 ). Just the file "2". I get: astro: updating host astro astro: /lynx/wls/play2/2: updating astro: remote error: /a/wls/rdista04596 -> /a/wls/play2: rename failed: Is a directory astro: updating of astro finished Obviously it thinks that it should be making the remote file be /a/wls/play2 rather than /a/wls/play2/2. I know that often this is what one wants. However it would still seem to me that the remote rdistd knows that the file name given in the install command is a directory rather than a plain file and it could move the file inside the directory just like the unix "cp" command knows the difference between "cp file1 file2" and "cp file1 directory". Grammatically it would seem that the other interpretation would be to remove that directory and replace it with the file but obviously it did not do that either. I think that the meaning of the pathname mentioned in the install command should be cleared up. As I mentioned I have been bitten by this before. However the use of set arithmetic makes the problem much worse as the grammar of the install command then depends on the results of the set arithmetic. This could easily be invoked if due to changing circumstances, files were removed from a list until only one remained in the result. One final test involved again clearing out the destination directory and changing the Distfile to: ================= a = ( 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= This leaves variable c containing nothing. I get: astro: updating host astro astro: /a/wls/play2: chmod from 755 to 2755 astro: /lynx/wls/play2//Distfile: installing astro: /lynx/wls/play2//1: installing astro: /lynx/wls/play2//2: installing astro: /lynx/wls/play2//3: installing astro: /lynx/wls/play2//4: installing astro: /lynx/wls/play2//5: installing astro: /lynx/wls/play2//6: installing astro: updating of astro finished Here it seems to have wanted to send over the whole directory. If it treats the empty list as a list containing one element, the null string, then this is explainable. However I think that this is wrong behaviour. I think that it would be more logical, especially in the context of set arithmetic if this operation had done nothing. This is the behavior of my symbolic link maintenance "maintlinks" and is a feature that is often used. Again one could be removing files from a set of files till none remained in the result. The result here could be quite a surprise. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From dbeusee@us.oracle.com Thu Feb 18 12:14:25 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05113; Thu, 18 Feb 93 12:14:25 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA21489; Thu, 18 Feb 93 12:13:46 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29677; Thu, 18 Feb 93 11:57:14 PST Message-Id: <9302181957.AA29677@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 11:57:14 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu I put $BRFILE ($BASEREMFILE) there so that the remote system does not need to do a basename command. Also, this allows porting rdist to non-unix systems. One alternative is to use: special "cd /usr/local/bin;B=$BASEREMPATH;rm -f $B; ln -s $B.ptx $B"; NOTE: you don't use $$ in rdist. THis would give B. From rsalz@osf.org Thu Feb 18 07:16:07 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29163; Thu, 18 Feb 93 07:16:06 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA07948; Thu, 18 Feb 93 07:22:37 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24332; Thu, 18 Feb 93 10:20:02 -0500 Received: by earth.osf.org (5.65/4.7) id AA03693; Thu, 18 Feb 93 10:20:00 -0500 Date: Thu, 18 Feb 93 10:20:00 -0500 From: rsalz@osf.org Message-Id: <9302181520.AA03693@earth.osf.org> To: dbeusee@us, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R >Obviously it can get ugly when the command wraps to the next line. Does rdist handle backslash-return "the right way" in quoted strings? If not, it probably should: special "cd /usr/local/bin; \ rm -f $BASEREMFILE; \ ln -s $BASEREMFILE.ptx $BASEREMFILE"; Note that this can be written with only one special var if you use the "basename" command: special "cd /usr/local/bin; \ B=`basename $REMFILE`; \ rm -f $$B; \ ln -s $$B.ptx $$B"; From dbeusee@us.oracle.com Thu Feb 18 12:35:51 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05805; Thu, 18 Feb 93 12:35:51 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA22579; Thu, 18 Feb 93 12:35:37 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29809; Thu, 18 Feb 93 12:29:01 PST Message-Id: <9302182029.AA29809@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 12:29:01 PST From: Don Beusee To: mcooper@usc.edu, wls@astro.UMD.EDU Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Thats exactly why I added the new ones. From mcooper@skat.usc.edu Thu Feb 18 10:17:49 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29533; Thu, 18 Feb 93 10:17:48 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA16017; Thu, 18 Feb 93 10:24:18 PST Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29496; Thu, 18 Feb 93 10:02:16 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00368; Thu, 18 Feb 93 10:02:15 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 10:02:14 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: Your message of Thu, 18 Feb 1993 10:29:20 -0500 Message-Id: Status: R Changing the behavior of $FILE breaks backwards compatibility with Distfiles. I think it's safer to add a new variable that people can explicitly use. mike From rsalz@osf.org Thu Feb 18 12:36:14 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05826; Thu, 18 Feb 93 12:36:14 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA15463; Thu, 18 Feb 93 15:36:09 -0500 Received: by earth.osf.org (5.65/4.7) id AA04726; Thu, 18 Feb 93 15:36:08 -0500 Date: Thu, 18 Feb 93 15:36:08 -0500 From: rsalz@osf.org Message-Id: <9302182036.AA04726@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu > special "cd /usr/local/bin;B=$BASEREMPATH;rm -f $B; ln -s $B.ptx $B"; Does this really work? How do you know $B is the shell var, but $BASEREMPATH is the rdist var? >porting rdist to non-unix systems. Ha and good luck! I tried to port it to VMS and gave up and wrote coda (c.s.unix archives) instead. From dbeusee@us.oracle.com Thu Feb 18 12:40:05 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05898; Thu, 18 Feb 93 12:40:05 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA22756; Thu, 18 Feb 93 12:39:52 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29849; Thu, 18 Feb 93 12:33:16 PST Message-Id: <9302182033.AA29849@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 12:33:16 PST From: Don Beusee To: rdist-dev@usc.edu, wls@astro.UMD.EDU Subject: Re: small enhancement patch I have some distfiles that does something like this: local/bin/f -> myhost install /usr/local/bin/f; special "ls -l /usr/$FILE"; From wls@astro.UMD.EDU Thu Feb 18 10:31:19 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29565; Thu, 18 Feb 93 10:31:18 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA16783; Thu, 18 Feb 93 10:37:44 PST Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29798; Thu, 18 Feb 93 10:05:45 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA16259; Thu, 18 Feb 1993 13:05:45 -0500 Date: Thu, 18 Feb 1993 13:05:45 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181805.AA16259@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: small enhancement patch Status: R > From: Michael A. Cooper > Changing the behavior of $FILE breaks backwards compatibility with Distfiles. > I think it's safer to add a new variable that people can explicitly use. True, but I never could figure out the use of the old behavior, except perhaps in some sort of logging. --- Bill From dbeusee@us.oracle.com Thu Feb 18 13:01:12 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06674; Thu, 18 Feb 93 13:01:12 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA23836; Thu, 18 Feb 93 13:00:32 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29921; Thu, 18 Feb 93 12:53:56 PST Message-Id: <9302182053.AA29921@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 12:53:56 PST From: Don Beusee To: rdist-dev@usc.edu, wls@astro.UMD.EDU Subject: Re: list awkwardness I think rdist is behaving properly. You can get what you want by: d = /lynx/wls/play2 a = ( $d/3 $d/4 ) b = ( $d/3 $d/4 $d/5 $d/6 ) c = ( ${a} - ${b} ) ${c} -> astro install /a/wls/play2; ================= Regards, Don. From wls@astro.UMD.EDU Thu Feb 18 12:12:51 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29739; Thu, 18 Feb 93 12:12:48 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA21760; Thu, 18 Feb 93 12:19:16 PST Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04307; Thu, 18 Feb 93 11:53:50 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA17617; Thu, 18 Feb 1993 14:53:50 -0500 Date: Thu, 18 Feb 1993 14:53:50 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181953.AA17617@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: list awkwardness Status: R The seems to be an awkwardness with the use of lists that get down to 1 or 0 elements. I came across this again when I was testing out the '&' option that I just posted but it has bitten me again in other forms in the past. The setup: I have two directories, /lynx/wls/play2 on machine lynx, and /a/wls/play2 on machine astro. First directory has a "Distfile" and 6 files named "1", "2", "3", "4", "5", and "6". The second directory is empty. The contents of the Distfile is initially: ================= a = ( 1 2 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= I get: astro: updating host astro astro: /lynx/wls/play2/2: installing astro: /lynx/wls/play2/1: installing astro: updating of astro finished So far so good, c should contain the set ( 1 2 ). Then I cleared out the the destination directory and changed the Distfile to: ================= a = ( 2 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= removing the 1st file. c should now contain ( 2 ). Just the file "2". I get: astro: updating host astro astro: /lynx/wls/play2/2: updating astro: remote error: /a/wls/rdista04596 -> /a/wls/play2: rename failed: Is a directory astro: updating of astro finished Obviously it thinks that it should be making the remote file be /a/wls/play2 rather than /a/wls/play2/2. I know that often this is what one wants. However it would still seem to me that the remote rdistd knows that the file name given in the install command is a directory rather than a plain file and it could move the file inside the directory just like the unix "cp" command knows the difference between "cp file1 file2" and "cp file1 directory". Grammatically it would seem that the other interpretation would be to remove that directory and replace it with the file but obviously it did not do that either. I think that the meaning of the pathname mentioned in the install command should be cleared up. As I mentioned I have been bitten by this before. However the use of set arithmetic makes the problem much worse as the grammar of the install command then depends on the results of the set arithmetic. This could easily be invoked if due to changing circumstances, files were removed from a list until only one remained in the result. One final test involved again clearing out the destination directory and changing the Distfile to: ================= a = ( 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= This leaves variable c containing nothing. I get: astro: updating host astro astro: /a/wls/play2: chmod from 755 to 2755 astro: /lynx/wls/play2//Distfile: installing astro: /lynx/wls/play2//1: installing astro: /lynx/wls/play2//2: installing astro: /lynx/wls/play2//3: installing astro: /lynx/wls/play2//4: installing astro: /lynx/wls/play2//5: installing astro: /lynx/wls/play2//6: installing astro: updating of astro finished Here it seems to have wanted to send over the whole directory. If it treats the empty list as a list containing one element, the null string, then this is explainable. However I think that this is wrong behaviour. I think that it would be more logical, especially in the context of set arithmetic if this operation had done nothing. This is the behavior of my symbolic link maintenance "maintlinks" and is a feature that is often used. Again one could be removing files from a set of files till none remained in the result. The result here could be quite a surprise. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From dbeusee@us.oracle.com Thu Feb 18 13:07:59 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07033; Thu, 18 Feb 93 13:07:59 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA24199; Thu, 18 Feb 93 13:07:52 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29974; Thu, 18 Feb 93 13:01:17 PST Message-Id: <9302182101.AA29974@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 13:01:17 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Rdist passes the special string to the following command to sh -c: FILE=..;BFILE=..;RFILE=..;RBFILE=..;export FILE BFILE RFILE RBFILE; This is how I know. Rdist does not do anything like make to pre-process $VAR in the special command string. Regards, Don. From rsalz@osf.org Thu Feb 18 12:30:35 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29822; Thu, 18 Feb 93 12:30:34 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA22638; Thu, 18 Feb 93 12:37:05 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA15463; Thu, 18 Feb 93 15:36:09 -0500 Received: by earth.osf.org (5.65/4.7) id AA04726; Thu, 18 Feb 93 15:36:08 -0500 Date: Thu, 18 Feb 93 15:36:08 -0500 From: rsalz@osf.org Message-Id: <9302182036.AA04726@earth.osf.org> To: dbeusee@us, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R > special "cd /usr/local/bin;B=$BASEREMPATH;rm -f $B; ln -s $B.ptx $B"; Does this really work? How do you know $B is the shell var, but $BASEREMPATH is the rdist var? >porting rdist to non-unix systems. Ha and good luck! I tried to port it to VMS and gave up and wrote coda (c.s.unix archives) instead. From wls@astro.UMD.EDU Thu Feb 18 13:23:54 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07434; Thu, 18 Feb 93 13:23:54 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA18605; Thu, 18 Feb 1993 16:17:26 -0500 Date: Thu, 18 Feb 1993 16:17:26 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302182117.AA18605@lynx.astro.umd.edu> To: dbeusee@us.oracle.com Subject: Re: list awkwardness Cc: rdist-dev@usc.edu > I think rdist is behaving properly. You can get what you want by: > d = /lynx/wls/play2 > a = ( $d/3 $d/4 ) > b = ( $d/3 $d/4 $d/5 $d/6 ) > c = ( ${a} - ${b} ) > > ${c} -> astro > install /a/wls/play2; This was instead of > ================= a = ( 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= No I don't think that rdist is behaving properly when in the latter example it concatenates a null string with /local/wls/play2/ and sends the whole directory, even though your revised example works properly (it returns: astro: local error: No files to be updated on astro for target "(null)" I could argue nits that should not be called "local error" because this might not necessarily be an error.) For the 1 entry list case rewriting the Distfile this way doesn't help. When one adds another entry to variable "a" so that "c" ends up with one entry the behavior is the same, it tries to copy that file to /a/wls/play2 rather than put the file inside directory /a/wls/play2. However when "c" ends up with two entries then they both get put inside the /a/wls/play2. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From aad@lovecraft.siemens.com Thu Feb 18 13:24:04 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07439; Thu, 18 Feb 93 13:24:04 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nPIjX-0019AyC; Thu, 18 Feb 93 16:24 EST Received: by lovecraft (4.1/SMI-4.1) id AA04532; Thu, 18 Feb 93 16:23:55 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Thu, 18 Feb 1993 16:23:54 -0500 (EST) Message-Id: Date: Thu, 18 Feb 1993 16:23:54 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: <9302182033.AA29849@dbeusee.us.oracle.com> References: <9302182033.AA29849@dbeusee.us.oracle.com> >True, but I never could figure out the use of the old behavior, except perhaps >in some sort of logging. I used it with stock Sun/Convex rdist to workaround some of the annoying bugs wrt hard links, symlinks, and the fact that installing into a different directory usually failed miserably. At one point I even had to leave off the leading / to get things to install into a different directory. It worked since this dist ran as root. Arrghghghghghgh. When I fetched 6.0 and read through the docs, it was great to see that most of the annoying shortcomings and bugs had been fixed. cmdspecial is a godsend, as is list subtraction. I've wanted set manipulations for a long time, but since I generate the distfile headers from a perl script that reads a configuration database anyway, I can just define variables there at will. ======================================================================8--< From dbeusee@us.oracle.com Thu Feb 18 14:33:12 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09958; Thu, 18 Feb 93 14:33:12 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA27645; Thu, 18 Feb 93 14:17:55 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00317; Thu, 18 Feb 93 14:11:15 PST Message-Id: <9302182211.AA00317@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 14:11:15 PST From: Don Beusee To: wls@astro.UMD.EDU Subject: Re: list awkwardness Cc: rdist-dev@usc.edu This is because rdist does not know if you intend for it to install it as a FILE, but on some remote system it might exist as a DIRECTORY). Rdist wants you to clarify it - I think that is reasonable. Maybe a new option to the install directive to indicate that the destination is a directory: install -odirectory /a/wls/play2; Regards, Don. From wls@astro.UMD.EDU Thu Feb 18 13:31:56 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00215; Thu, 18 Feb 93 13:31:55 PST Received: from lynx.astro.umd.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA25592; Thu, 18 Feb 93 13:38:14 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA18605; Thu, 18 Feb 1993 16:17:26 -0500 Date: Thu, 18 Feb 1993 16:17:26 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302182117.AA18605@lynx.astro.umd.edu> To: dbeusee@us Subject: Re: list awkwardness Cc: rdist-dev@usc.edu Status: R > I think rdist is behaving properly. You can get what you want by: > d = /lynx/wls/play2 > a = ( $d/3 $d/4 ) > b = ( $d/3 $d/4 $d/5 $d/6 ) > c = ( ${a} - ${b} ) > > ${c} -> astro > install /a/wls/play2; This was instead of > ================= a = ( 3 4 ) b = ( 3 4 5 6 ) c = ${a} - ${b} ( /lynx/wls/play2/${c} ) -> astro install /a/wls/play2; ================= No I don't think that rdist is behaving properly when in the latter example it concatenates a null string with /local/wls/play2/ and sends the whole directory, even though your revised example works properly (it returns: astro: local error: No files to be updated on astro for target "(null)" I could argue nits that should not be called "local error" because this might not necessarily be an error.) For the 1 entry list case rewriting the Distfile this way doesn't help. When one adds another entry to variable "a" so that "c" ends up with one entry the behavior is the same, it tries to copy that file to /a/wls/play2 rather than put the file inside directory /a/wls/play2. However when "c" ends up with two entries then they both get put inside the /a/wls/play2. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Thu Feb 18 14:35:40 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10006; Thu, 18 Feb 93 14:35:40 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA19329; Thu, 18 Feb 1993 17:32:53 -0500 Date: Thu, 18 Feb 1993 17:32:53 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302182232.AA19329@lynx.astro.umd.edu> To: dbeusee@us.oracle.com Subject: Re: list awkwardness Cc: rdist-dev@usc.edu > This is because rdist does not know if you intend for it to install it as a > FILE, but on some remote system it might exist as a DIRECTORY). Rdist wants > you to clarify it - I think that is reasonable. > Regards, > Don. But it does not now do that correctly. If the source is a file and the destination is a directory it does not remove the directory and copy the file. Instead one gets that "Cannot rename" error. What I object to is when a list is whittled down to one entry the destination suddenly stops being treated as a directory in which to put the file and instead is treated as the name of the file. I think that the princple of least surprise would dictate that the behavior should be the same no matter what the size of the file list. The only time I can see wanting the present behavior, is when there is a file on the master host and on the same host there is an empty directory, and one wanted the directory to be removed and replaced with a file. I believe that this situation occurs rarely. And if the directory on the slave is non-empty then allowing rdist to remove it and its contents would be very dangerous. > Maybe a new option to the install directive to indicate that the destination > is a directory: > install -odirectory /a/wls/play2; I think that the present be behavior (again assuming that it would be fixed to actually remove the directory) should what requires the option. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From dbeusee@us.oracle.com Thu Feb 18 14:42:24 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10256; Thu, 18 Feb 93 14:42:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA22134; Thu, 18 Feb 93 12:26:04 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29764; Thu, 18 Feb 93 12:19:19 PST Message-Id: <9302182019.AA29764@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 12:19:19 PST From: Don Beusee To: rdist-dev@usc.edu, wls@astro.UMD.EDU Subject: Re: Port of new rdist to multiflow Yes, ${MAKE} needs to be ${Make} (I had that problem too) I also changed that makefile with the if's from @ to @- to ignore the error (pyrOSx has the same problem). From wls@astro.UMD.EDU Thu Feb 18 09:09:07 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29417; Thu, 18 Feb 93 09:09:05 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA12599; Thu, 18 Feb 93 09:15:34 PST Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26809; Thu, 18 Feb 93 08:43:26 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA15522; Thu, 18 Feb 1993 11:43:25 -0500 Date: Thu, 18 Feb 1993 11:43:25 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302181643.AA15522@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Port of new rdist to multiflow Status: R Here is the stuff to port rdist-6.1.0 to the Multiflow. The multiflow's make doesn't automatically define the variable MAKE. Therefore the support/Makefile and doc/Makefile fail. I changed them to be like the other makefiles. There was also a problem that had my hair tearing out. It appears that the Multiflow's Bourne shell called by a Makefile will exit if a command returns non-zero (i.e. "bad") status, even if the command is after an "if". This made all of the tests in mf/Makefile.top completely hopeless. I solved that problem by giving up on the Multiflow's Bourne shell and replacing it with a more modern one. First come the patches: --- Cut HERE--- *** config/os-type.ORIG Tue Jan 5 17:52:31 1993 --- config/os-type Tue Feb 16 12:13:54 1993 *************** *** 75,80 **** --- 75,81 ---- fi;; *"Alliant Concentrix"*) OS=concen;; *"Umax 4.3"*) OS=umax43;; + *"Multiflow 4.3 BSD"*) OS=tracebsd;; *) # # Well, that didn't work so apply some heuristics *** doc/Makefile.ORIG Wed Jan 6 21:58:45 1993 --- doc/Makefile Wed Feb 17 14:35:36 1993 *************** *** 34,44 **** # $Id: Makefile,v 6.2 1993/01/07 02:58:40 mcooper Exp mcooper $ # MKARG = -f ../mf/Makefile.top TARGET=doc all: doc doc clean install install.man: FRC ! @${MAKE} ${MKARG} $@ FRC: --- 34,46 ---- # $Id: Makefile,v 6.2 1993/01/07 02:58:40 mcooper Exp mcooper $ # + Make = make + MAK = ${Make} Make="${Make}" MKARG = -f ../mf/Makefile.top TARGET=doc all: doc doc clean install install.man: FRC ! @${MAK} ${MKARG} $@ FRC: *** support/Makefile.ORIG Wed Feb 17 14:37:01 1993 --- support/Makefile Wed Feb 17 14:36:39 1993 *************** *** 33,43 **** # # $Id: Makefile,v 6.2 1993/01/07 02:58:49 mcooper Exp mcooper $ # MKARG = -f ../mf/Makefile.top TARGET=support all: support support clean install install.man: FRC ! @${MAKE} ${MKARG} $@ FRC: --- 33,45 ---- # # $Id: Makefile,v 6.2 1993/01/07 02:58:49 mcooper Exp mcooper $ # + Make = make + MAK = ${Make} Make="${Make}" MKARG = -f ../mf/Makefile.top TARGET=support all: support support clean install install.man: FRC ! @${MAK} ${MKARG} $@ FRC: --- End Cut HERE--- Then come the files to be installed in config/ --- Cut HERE and extract with sh --- #! /bin/sh # This is a shell archive. Remove anything before this line, then feed it # into a shell via "sh file" or similar. To overwrite existing files, # type "sh file -c". # The tool that generated this appeared in the comp.sources.unix newsgroup; # send mail to comp-sources-unix@uunet.uu.net if you want that tool. # Contents: mf.tracebsd os-tracebsd.h # Wrapped by wls@lynx on Thu Feb 18 11:32:36 1993 PATH=/bin:/usr/bin:/usr/ucb ; export PATH echo If this archive is complete, you will see the following message: echo ' "shar: End of archive."' if test -f 'mf.tracebsd' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'mf.tracebsd'\" else echo shar: Extracting \"'mf.tracebsd'\" \(2151 characters\) sed "s/^X//" >'mf.tracebsd' <<'END_OF_FILE' X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.TRACEBSD,v 6.1 1993/01/07 02:44:08 mcooper Exp $ X# X X# X# Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strerror.o $(O)strcasecmp.o $(O)strdup.o $(O)regex.o X X# X# System libraries that we need to load. X# X#LIB_OS = -lPW END_OF_FILE if test 2151 -ne `wc -c <'mf.tracebsd'`; then echo shar: \"'mf.tracebsd'\" unpacked with wrong size! fi # end of 'mf.tracebsd' fi if test -f 'os-tracebsd.h' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'os-tracebsd.h'\" else echo shar: Extracting \"'os-tracebsd.h'\" \(3328 characters\) sed "s/^X//" >'os-tracebsd.h' <<'END_OF_FILE' X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-TEMPLATE.h,v 1.1 1993/02/16 02:13:11 mcooper Exp $ X * @(#)os-TEMPLATE.h X */ X X/* X * TEMPLATE os-*.h file X */ X X/* X * Define the following name for use in #ifdef's. X * The value should be all upper-case with no periods (.). X */ X#if !defined(TRACEBSD) X#define TRACEBSD X#endif X X/* X * Set process args to messages that show up when running ps(1) X * X * Under some OS's, the SETARGS code will cause ": is not an identifier" X * errors for "special" commands. X */ X#define SETARGS X X/* X * Define the type of directory routines your system has. X */ X#define DIR_TYPE DIR_DIRECT X X/* X * Determine what routines we have to get filesystem info. X */ X#define FSI_TYPE FSI_GETMNTENT X X/* X * Type of non-blocking I/O. X */ X#define NBIO_TYPE NBIO_FCNTL X X/* X * Type of wait() function to use. X */ X#define WAIT_TYPE WAIT_WAIT3 X X/* X * Type of argument passed to wait() (above). X */ X#define WAIT_ARG_TYPE union wait X X/* X * Select the type of executable file format. X */ X#define EXE_TYPE EXE_AOUT X X/* X * Select the type of statfs() system call (if any). X */ X#define STATFS_TYPE STATFS_BSD X X/* X * Type of arg functions we have. X */ X#define ARG_TYPE ARG_VARARGS X X/* X * Do we have select()? X */ X#define HAVE_SELECT X X/* X * UID argument type for chown() X */ Xtypedef uid_t CHOWN_UID_T; X X/* X * GID argument type for chown() X */ Xtypedef int CHOWN_GID_T; X X/* X * Our types, usually these are uid_t and gid_t. X */ Xtypedef int UID_T; /* Must be signed */ Xtypedef int GID_T; /* Must be signed */ END_OF_FILE if test 3328 -ne `wc -c <'os-tracebsd.h'`; then echo shar: \"'os-tracebsd.h'\" unpacked with wrong size! fi # end of 'os-tracebsd.h' fi echo shar: End of archive. exit 0 --- End Cut HERE--- Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From dbeusee@us.oracle.com Thu Feb 18 19:49:14 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21221; Thu, 18 Feb 93 19:49:14 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11106; Thu, 18 Feb 93 19:48:17 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00899; Thu, 18 Feb 93 19:41:42 PST Message-Id: <9302190341.AA00899@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 19:41:42 PST From: Don Beusee To: wls@astro.UMD.EDU Subject: Re: list awkwardness Cc: rdist-dev@usc.edu I am not proposing (and in fact am against it because it is dangerous) for rdist to wipe out a directory with a plain file. I think the current safety feature to return an error if local is a file and remote is a directory (empty or not). I am only proposing that an option like -odirectory (actually I like -odestdir better) be used to indicate that the destination is a directory and that the file should be put in that directory, so that the following would work: file -> host install -odestdir remdir; This allows the following to work as well (which matches your scenerio): ((file1 file2) - file2) -> host install -odestdir remdir; From wls@astro.UMD.EDU Thu Feb 18 14:29:07 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00389; Thu, 18 Feb 93 14:29:05 PST Received: from lynx.astro.umd.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA28401; Thu, 18 Feb 93 14:35:33 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA19329; Thu, 18 Feb 1993 17:32:53 -0500 Date: Thu, 18 Feb 1993 17:32:53 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302182232.AA19329@lynx.astro.umd.edu> To: dbeusee@us Subject: Re: list awkwardness Cc: rdist-dev@usc.edu Status: R > This is because rdist does not know if you intend for it to install it as a > FILE, but on some remote system it might exist as a DIRECTORY). Rdist wants > you to clarify it - I think that is reasonable. > Regards, > Don. But it does not now do that correctly. If the source is a file and the destination is a directory it does not remove the directory and copy the file. Instead one gets that "Cannot rename" error. What I object to is when a list is whittled down to one entry the destination suddenly stops being treated as a directory in which to put the file and instead is treated as the name of the file. I think that the princple of least surprise would dictate that the behavior should be the same no matter what the size of the file list. The only time I can see wanting the present behavior, is when there is a file on the master host and on the same host there is an empty directory, and one wanted the directory to be removed and replaced with a file. I believe that this situation occurs rarely. And if the directory on the slave is non-empty then allowing rdist to remove it and its contents would be very dangerous. > Maybe a new option to the install directive to indicate that the destination > is a directory: > install -odirectory /a/wls/play2; I think that the present be behavior (again assuming that it would be fixed to actually remove the directory) should what requires the option. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From rouilj@cs.umb.edu Thu Feb 18 20:09:34 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21975; Thu, 18 Feb 93 20:09:34 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA13778 (5.65c/IDA-1.4.4 for ); Thu, 18 Feb 1993 23:09:29 -0500 Message-Id: <199302190409.AA13778@cs.umb.edu> To: rdist-dev@usc.edu Subject: Bug in freespace code. Date: Thu, 18 Feb 1993 23:09:28 -0500 From: "John P. Rouillard" After two hours of work, I just figured out one of the basic rules of divison. Under some OS's like Irix, the size of a block < 1024. So the line of code in getfilesysinfo() that reads: *freespace = statfsbuf.f_bavail * (statfsbuf.f_bsize / 1024) always assigns 0 to *freespace, since it is obvious to the reader that 512/1024 = 0. The fix I used was to explicitly cast statfsbuf.f_bsize to double. So the code now reads: *freespace = statfsbuf.f_bavail * ((double) statfsbuf.f_bsize / 1024) I assume changing 1024 to 1024.0 would also work. Other buglet: The mf.TEMPLATE file uses LIB_OS which should really be LIB_SYS. Also, the makefiles won't work with the system 5 makes on the IRIX or the mips boxes. I use gnu make on the IRIX box, and /usr/bsd43/bin/make on the mips platform. The error I receive from the system V makes looks like: MAKING missing # ... No OS= option specified; dynamically determining OS type # checking to see what /bin/uname will tell me # ... inspecting File system ... # ... OS appears to be "riscos" Directory -f ../mf/Makefile.var -f ../Makefile.local -f ../config/: \ Make: Cannot open. Stop. I am not sure what the problem is. Sadly these makefiles don't work quite cleanly with gnu make either. The errors are: MAKING src # ... No OS= option specified; dynamically determining OS type # checking to see what /bin/uname will tell me # ... OS appears to be "irix4" MAKING config MAKING doc # ... No OS= option specified; dynamically determining OS type # ... OS appears to be "`PATH=$${PATH}:. /bin/sh ../config/os-type`" Your OS (`PATH=$${PATH}:. /bin/sh ../config/os-type`) is currently not supported. make[1]: *** [doc] Error 1 *** Error code 1 MAKING support # ... No OS= option specified; dynamically determining OS type # ... OS appears to be "`PATH=$${PATH}:. /bin/sh ../config/os-type`" Your OS (`PATH=$${PATH}:. /bin/sh ../config/os-type`) is currently not supported. make[1]: *** [support] Error 1 *** Error code 1 MAKING mf I am using gnumake 3.60, so if anybody knows that this is a bug with this make, please let me know. -- John BTW, I have patches for IRIX 4.0.5f and Mips RISCOS 4.52 available. Hopefully tomorrow, I will have SVR4, and sinix patches available. Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Thu Feb 18 20:46:24 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22934; Thu, 18 Feb 93 20:46:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA12497; Thu, 18 Feb 93 20:45:48 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00956; Thu, 18 Feb 93 20:39:12 PST Message-Id: <9302190439.AA00956@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 20:39:12 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu I have a better idea. How about just $FILE and $BASEFILE? Then we can have an option that determines what $FILE returns (local or remote name, with the default the remote name). How about -ofile=local or something like that? From mcooper@skat.usc.edu Thu Feb 18 09:54:26 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29483; Thu, 18 Feb 93 09:54:23 PST Received: from skat.usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA14782; Thu, 18 Feb 93 10:00:55 PST Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA14316; Thu, 18 Feb 93 09:58:21 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00336; Thu, 18 Feb 93 09:58:21 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 9:58:20 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rsalz@osf.org Cc: dbeusee@us, rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: Your message of Thu, 18 Feb 93 09:03:05 -0500 Message-Id: Status: RO How about REMFILE, BASEFILE, and BASEREMFILE? mike From dbeusee@us.oracle.com Thu Feb 18 22:50:20 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26521; Thu, 18 Feb 93 22:50:20 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA15085; Thu, 18 Feb 93 22:50:13 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01176; Thu, 18 Feb 93 22:43:38 PST Message-Id: <9302190643.AA01176@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 22:43:38 PST From: Don Beusee To: mcooper@usc.edu Subject: comments on rdist log format Cc: rdist-dev@usc.edu Currently, the log format is: : : <"updating"|"installing"|"need to .."> This should be changed to: : <"updating"|"installing"|"need to ..">: To make it more readable since the filename is variable length. Maybe the : and <"updating"|"installing">: can be padded so that most of it is aligned... Also, "remote error" and "local error" should both be in upper case to catch your attention. Some warnings should not include the filename, since the warning has nothing to do with the file itself - so the message can be confusing. Instead, "REMOTE WARNING:" should be printed. Here is the patch for this suggestion (shar file): #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.message.c # patch.server.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.3 1993/02/19 05:17:54 X--- src/client.c 1993/02/19 05:21:00 X*************** X*** 962,973 **** X */ X if (u == US_NOENT) { X if (IS_ON(opts, DO_VERIFY)) { X! message(MT_INFO, "%s: need to install", target); X runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X! message(MT_CHANGE, "%s: installing", target); X FLAG_OFF(opts, (DO_COMPARE|DO_REMOVE)); X } X X--- 962,973 ---- X */ X if (u == US_NOENT) { X if (IS_ON(opts, DO_VERIFY)) { X! message(MT_INFO, "need to install: %s", target); X runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X! message(MT_CHANGE, "installing: %s", target); X FLAG_OFF(opts, (DO_COMPARE|DO_REMOVE)); X } X X*************** X*** 990,1001 **** X case S_IFREG: X if (u == US_OUTDATE) { X if (IS_ON(opts, DO_VERIFY)) { X! message(MT_INFO, "%s: need to update", target); X runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X! message(MT_CHANGE, "%s: updating", target); X } X if (sendfile(rname, opts, &stb, user, group) == 0) X didupdate = 1; X--- 990,1001 ---- X case S_IFREG: X if (u == US_OUTDATE) { X if (IS_ON(opts, DO_VERIFY)) { X! message(MT_INFO, "need to update: %s", target); X runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X! message(MT_CHANGE, "updating: %s", target); X } X if (sendfile(rname, opts, &stb, user, group) == 0) X didupdate = 1; SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.message.c && X*** 1.2 1993/02/19 05:21:55 X--- src/message.c 1993/02/19 06:10:58 X*************** X*** 487,492 **** X--- 487,493 ---- X register int i, x; X register char *cp; X static char mbuf[2048]; X+ static char buf[12]; X X /* X * Ensure no stray newlines are present X*************** X*** 494,504 **** X if (cp = strchr(msgbuf, '\n')) X *cp = CNULL; X X checkhostname(); X! if (strncmp(currenthost, msgbuf, strlen(currenthost)) == 0) X! (void) strcpy(mbuf, msgbuf); X! else X! (void) sprintf(mbuf, "%s: %s", currenthost, msgbuf); X X /* X * Special case for messages that only get X--- 495,507 ---- X if (cp = strchr(msgbuf, '\n')) X *cp = CNULL; X X+ mbuf[0] = '\0'; X checkhostname(); X! if (strncmp(currenthost, msgbuf, strlen(currenthost)) != 0) { X! (void) sprintf(buf, "%s:", currenthost); X! (void) sprintf(mbuf, "%-10s", buf); /* pad to 10 bytes */ X! } X! (void) strcat(mbuf, msgbuf); X X /* X * Special case for messages that only get X*************** X*** 680,688 **** X nerrs++; X X if (isserver) X! (void) sprintf(buf, "remote error: %s", msg); X else X! (void) sprintf(buf, "local error: %s", msg); X X _message(MT_NERROR, buf); X } X--- 683,691 ---- X nerrs++; X X if (isserver) X! (void) sprintf(buf, "REMOTE ERROR: %s", msg); X else X! (void) sprintf(buf, "LOCAL ERROR: %s", msg); X X _message(MT_NERROR, buf); X } SHAR_EOF chmod 0644 patch.message.c || echo "restore of patch.message.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.server.c && X*** 1.1 1993/02/19 05:58:23 X--- src/server.c 1993/02/19 06:34:01 X*************** X*** 165,178 **** X if ((pw = getpwnam(owner)) == NULL) { X if (IS_ON(mode, S_ISUID)) { X message(MT_NOTICE, X! "%s: unknown login name \"%s\", clearing setuid", X! target, owner); X mode &= ~S_ISUID; X uid = 0; X } else X message(MT_NOTICE, X! "%s: unknown login name \"%s\"", X! target, owner); X } else X uid = pw->pw_uid; X } else { X--- 165,178 ---- X if ((pw = getpwnam(owner)) == NULL) { X if (IS_ON(mode, S_ISUID)) { X message(MT_NOTICE, X! "REMOTE WARNING: unknown login name \"%s\", clearing setuid", X! owner); X mode &= ~S_ISUID; X uid = 0; X } else X message(MT_NOTICE, X! "REMOTE WARNING: unknown login name \"%s\"", X! owner); X } else X uid = pw->pw_uid; X } else { X*************** X*** 202,214 **** X || ((gr = getgrnam(group)) == NULL)) { X if (IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "%s: unknown group \"%s\", clearing setgid", X! target, group); X mode &= ~S_ISGID; X } else X message(MT_NOTICE, X! "%s: unknown group \"%s\"", X! target, group); X } else X gid = gr->gr_gid; X } else X--- 202,214 ---- X || ((gr = getgrnam(group)) == NULL)) { X if (IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "REMOTE WARNING: unknown group \"%s\", clearing setgid", X! group); X mode &= ~S_ISGID; X } else X message(MT_NOTICE, X! "REMOTE WARNING: unknown group \"%s\"", X! group); X } else X gid = gr->gr_gid; X } else X*************** X*** 221,228 **** X goto ok; X if (mode != -1 && IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "%s: user %s not in group %s, clearing setgid", X! target, locuser, group); X mode &= ~S_ISGID; X } X gid = -1; X--- 221,228 ---- X goto ok; X if (mode != -1 && IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "REMOTE WARNING: user %s not in group %s, clearing setgid", X! locuser, group); X mode &= ~S_ISGID; X } X gid = -1; X*************** X*** 236,247 **** X if (setownership(file, fd, uid, gid) < 0) { X if (mode != -1 && IS_ON(mode, S_ISUID)) { X message(MT_NOTICE, X! "%s: chown failed, clearing setuid", target); X mode &= ~S_ISUID; X } X if (mode != -1 && IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "%s: chown failed, clearing setgid", target); X mode &= ~S_ISGID; X } X } X--- 236,247 ---- X if (setownership(file, fd, uid, gid) < 0) { X if (mode != -1 && IS_ON(mode, S_ISUID)) { X message(MT_NOTICE, X! "REMOTE WARNING: chown failed, clearing setuid"); X mode &= ~S_ISUID; X } X if (mode != -1 && IS_ON(mode, S_ISGID)) { X message(MT_NOTICE, X! "REMOTE WARNING: chown failed, clearing setgid"); X mode &= ~S_ISGID; X } X } SHAR_EOF chmod 0644 patch.server.c || echo "restore of patch.server.c fails" exit 0 From dbeusee@us.oracle.com Thu Feb 18 23:31:18 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27560; Thu, 18 Feb 93 23:31:18 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA15648; Thu, 18 Feb 93 23:19:22 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01239; Thu, 18 Feb 93 23:12:46 PST Message-Id: <9302190712.AA01239@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 23:12:46 PST From: Don Beusee To: mcooper@usc.edu Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu I made the following changes: 1. Added -olocalfilenames option. 2. RFILE renamed REMOTEFILE. BFILE renamed BASEFILE. FILE renamed LOCALFILE. 3. FILE set to REMOTEFILE. If -olocalfilenames, it is set to LOCALFILE. I will send the changes after they are tested. Regards, Don. From dbeusee@us Thu Feb 18 21:10:51 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01017; Thu, 18 Feb 93 21:10:49 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA13277; Thu, 18 Feb 93 21:17:17 PST Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22934; Thu, 18 Feb 93 20:46:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA12497; Thu, 18 Feb 93 20:45:48 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00956; Thu, 18 Feb 93 20:39:12 PST Message-Id: <9302190439.AA00956@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 20:39:12 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R I have a better idea. How about just $FILE and $BASEFILE? Then we can have an option that determines what $FILE returns (local or remote name, with the default the remote name). How about -ofile=local or something like that? >From mcooper@skat.usc.edu Thu Feb 18 09:54:26 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29483; Thu, 18 Feb 93 09:54:23 PST Received: from skat.usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA14782; Thu, 18 Feb 93 10:00:55 PST Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA14316; Thu, 18 Feb 93 09:58:21 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA00336; Thu, 18 Feb 93 09:58:21 PST Sender: "Michael A. Cooper" Date: Thu, 18 Feb 93 9:58:20 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rsalz@osf.org Cc: dbeusee@us, rdist-dev@usc.edu Subject: Re: small enhancement patch In-Reply-To: Your message of Thu, 18 Feb 93 09:03:05 -0500 Message-Id: Status: RO How about REMFILE, BASEFILE, and BASEREMFILE? mike From matt@aodc20.aodc.gov.au Thu Feb 18 23:53:05 1993 Return-Path: Received: from aodc20.aodc.gov.au by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28087; Thu, 18 Feb 93 23:53:05 PST Received: by aodc20.aodc.gov.au (5.65/1.35) id AA08830; Fri, 19 Feb 93 18:52:21 -0500 Date: Fri, 19 Feb 93 18:52:21 -0500 From: matt@aodc20.aodc.gov.au (Matthew Hannigan) Message-Id: <9302192352.AA08830@aodc20.aodc.gov.au> To: dbeusee@us.oracle.com, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Don Beusee writes.. Currently, the log format is: : : <"updating"|"installing"|"need to .."> This should be changed to: : <"updating"|"installing"|"need to ..">: To make it more readable since the filename is variable length. Maybe the : and <"updating"|"installing">: can be padded so that most of it is aligned... Wouldn't .. ::: be nice? -Matt Hannigan matt@aodc20.aodc.gov.au From dbeusee@us.oracle.com Fri Feb 19 00:04:08 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28308; Fri, 19 Feb 93 00:04:08 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA16436; Fri, 19 Feb 93 00:04:05 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01417; Thu, 18 Feb 93 23:57:30 PST Message-Id: <9302190757.AA01417@dbeusee.us.oracle.com> Date: Thu, 18 Feb 93 23:57:30 PST From: Don Beusee To: matt@aodc20.aodc.gov.au, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Filenames should be at the end. I will let Mike handle the and logging issue. Probably local and remote filenames in messages should be controlled with command line options for those of us who don't normally want both all the time due to the unreadability when long filenames are printed. From matt@aodc20.aodc.gov.au Thu Feb 18 23:46:18 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01335; Thu, 18 Feb 93 23:46:17 PST Received: from aodc20.aodc.gov.au by gatekeeper.oracle.com (5.59.11/37.7) id AA16212; Thu, 18 Feb 93 23:52:42 PST Received: by aodc20.aodc.gov.au (5.65/1.35) id AA08830; Fri, 19 Feb 93 18:52:21 -0500 Date: Fri, 19 Feb 93 18:52:21 -0500 From: matt@aodc20.aodc.gov.au (Matthew Hannigan) Message-Id: <9302192352.AA08830@aodc20.aodc.gov.au> To: dbeusee@us, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Status: R Don Beusee writes.. Currently, the log format is: : : <"updating"|"installing"|"need to .."> This should be changed to: : <"updating"|"installing"|"need to ..">: To make it more readable since the filename is variable length. Maybe the : and <"updating"|"installing">: can be padded so that most of it is aligned... Wouldn't .. ::: be nice? -Matt Hannigan matt@aodc20.aodc.gov.au From dbeusee@us.oracle.com Fri Feb 19 01:36:32 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01737; Fri, 19 Feb 93 01:36:32 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA18171; Fri, 19 Feb 93 01:36:28 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01938; Fri, 19 Feb 93 01:29:51 PST Message-Id: <9302190929.AA01938@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 01:29:51 PST From: Don Beusee To: mcooper@usc.edu Subject: more rdist patches (another hardlink bug fixed) Cc: rdist-dev@usc.edu This patch has the following changes/fixes: 1. Added -olocalfilenames option (for $FILE setting). 2. RFILE renamed REMOTEFILE. BFILE renamed BASEFILE. FILE renamed LOCALFILE. 3. FILE set to REMOTEFILE. If -olocalfilenames, it is set to LOCALFILE. So in the "special" command, you can use: $FILE set to $REMOTEFILE by default, or to $LOCALFILE if -olocalfilenames specified. $LOCALFILE previously known as $FILE and is the filename on the local system. $REMOTEFILE this is the file pathname on the remote system. $BASEFILE this is same as `basename $REMOTEFILE`. 4. Fixed bug with hardlink and $REMOTEFILE set wrong when destdir=true. e.g. (a b) -> /tmp ========= While testing, I noticed a bug when an error occurs (looks like the client and server get out of sync): dbeusee: updating: d dbeusee: REMOTE ERROR: rdista01894 -> a: rename failed: Is a directory dbeusee: LOCAL ERROR: update: unexpected response '' dbeusee: Y0 730112541 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response '' dbeusee: Y0 730112541 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response '' dbeusee: Y0 730112541 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response '' I don't think my changes could have caused this. Here is the distfile in case anyone wants to try to fix it: HOST=dbeusee x -> ${HOST} install /tmp/tx; special "printenv|grep FILE"; y -> ${HOST} install y ; special "printenv|grep FILE"; z -> ${HOST} install ; special "printenv|grep FILE"; c -> ${HOST} install b ; special "printenv|grep FILE"; d -> ${HOST} install a ; special "printenv|grep FILE"; /tmp/z -> ${HOST} install ; special "printenv|grep FILE"; /tmp/y -> ${HOST} install /tmp/x ; special "printenv|grep FILE"; (/tmp/a /tmp/b) -> ${HOST} install /tmp ; special "printenv|grep FILE"; (a b) -> ${HOST} install /tmp ; special "printenv|grep FILE"; e -> ${HOST} install ; special "printenv|grep FILE"; Just make the /a directory on ${HOST} and do the following commands on the local machine: touch a b c d x y z /tmp/z /tmp/y /tmp/a /tmp/b touch e/a e/b e/c rdist Let me know what you find. If you fix it, please send me the patch. The shar file (containing diffs) for fixes #1 - #4 above follows... Regards, Don. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.defs.h # patch.distopt.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.4 1993/02/19 06:50:47 X--- src/client.c 1993/02/19 08:56:20 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 1.4 1993/02/19 06:50:47 dbeusee Exp dbeusee $"; X X static char sccsid[] = "@(#)client.c"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 1.4 1993/02/19 06:50:47 dbeusee Exp $"; X X static char sccsid[] = "@(#)client.c"; X X*************** X*** 83,100 **** X * return remote file pathname (relative from target) X */ X char * X! remfilename(src, dest, path) X! char *src, *dest, *path; X { X static char *lname, *cp, buff[BUFSIZ]; X X! debugmsg(DM_MISC, "remfilename: src=%s, dest=%s, path=%s\n", X! src, dest, path); X if (path && *path) { X lname = strrchr(path, '/'); X! if (lname == NULL) X lname = path; X! else { X lname = cp = buff; X strcpy(cp, dest); X cp += strlen(cp); X--- 83,106 ---- X * return remote file pathname (relative from target) X */ X char * X! remfilename(src, dest, path, rname, destdir) X! char *src, *dest, *path, *rname; X! int destdir; X { X static char *lname, *cp, buff[BUFSIZ]; X X! debugmsg(DM_MISC, X! "remfilename: src=%s, dest=%s, path=%s, rname=%s, destdir=%d\n", X! src, dest, path, rname, destdir); X if (path && *path) { X lname = strrchr(path, '/'); X! if ((lname == NULL) || (path && *path == '/')) { X lname = path; X! if (destdir) { X! strcat(lname, "/"); X! strcat(lname, rname); X! } X! } else { X lname = cp = buff; X strcpy(cp, dest); X cp += strlen(cp); X*************** X*** 104,109 **** X--- 110,119 ---- X path++; src++; X } X strcat(cp, path); X+ if (destdir) { X+ strcat(lname, "/"); X+ strcat(lname, rname); X+ } X } X } else { X lname = buff; X*************** X*** 133,147 **** X * Run any special commands for this file X */ X static void X! runspecial(starget, opts) X! char *starget; X! int opts; X { X register struct subcmd *sc; X extern struct subcmd *subcmds; X char *rfile; X X! rfile = remfilename(source, target, Tdest); X X for (sc = subcmds; sc != NULL; sc = sc->sc_next) { X if (sc->sc_type != SPECIAL) X--- 143,157 ---- X * Run any special commands for this file X */ X static void X! runspecial(starget, opts, rname, destdir) X! char *starget, *rname; X! int opts, destdir; X { X register struct subcmd *sc; X extern struct subcmd *subcmds; X char *rfile; X X! rfile = remfilename(source, target, Tdest, rname, destdir); X X for (sc = subcmds; sc != NULL; sc = sc->sc_next) { X if (sc->sc_type != SPECIAL) X*************** X*** 153,163 **** X continue; X (void) sendcmd(C_SPECIAL, X "%s=%s;%s=%s;%s=%s;%s=%s;export %s %s %s %s;%s", X! E_SFILE, starget, X E_SRFILE, rfile, X! E_SBFILE, basename(starget), X! E_SBRFILE, basename(rfile), X! E_SFILE, E_SRFILE, E_SBFILE, E_SBRFILE, X sc->sc_name); X while (response() > 0) X ; X--- 163,173 ---- X continue; X (void) sendcmd(C_SPECIAL, X "%s=%s;%s=%s;%s=%s;%s=%s;export %s %s %s %s;%s", X! E_SFILE, IS_ON(opts, DO_LOCALFILENAMES)?starget:rfile, X! E_SLFILE, starget, X E_SRFILE, rfile, X! E_SBFILE, basename(rfile), X! E_SFILE, E_SLFILE, E_SRFILE, E_SBFILE, X sc->sc_name); X while (response() > 0) X ; X*************** X*** 254,261 **** X * Send a hardlink X */ X static int X! sendhardlink(opts, lp, rname) X! int opts; X struct linkbuf *lp; X char *rname; X { X--- 264,271 ---- X * Send a hardlink X */ X static int X! sendhardlink(opts, lp, rname, destdir) X! int opts, destdir; X struct linkbuf *lp; X char *rname; X { X*************** X*** 278,284 **** X } else { X lname = buff; X strcpy(lname, remfilename(lp->src, X! lp->target, lp->pathname)); X } X debugmsg(DM_MISC, "sendhardlink: lname=%s\n", lname); X (void) sendcmd(C_RECVHARDLINK, "%o %s %s", X--- 288,294 ---- X } else { X lname = buff; X strcpy(lname, remfilename(lp->src, X! lp->target, lp->pathname, rname, destdir)); X } X debugmsg(DM_MISC, "sendhardlink: lname=%s\n", lname); X (void) sendcmd(C_RECVHARDLINK, "%o %s %s", X*************** X*** 292,300 **** X * Send a file X */ X static int X! sendfile(rname, opts, stb, user, group) X char *rname; X! int opts; X struct stat *stb; X char *user, *group; X { X--- 302,310 ---- X * Send a file X */ X static int X! sendfile(rname, opts, stb, user, group, destdir) X char *rname; X! int opts, destdir; X struct stat *stb; X char *user, *group; X { X*************** X*** 305,311 **** X struct linkbuf *lp; X X if ((lp = linkinfo(stb)) != NULL) X! return(sendhardlink(opts, lp, rname)); X } X X if ((f = open(target, O_RDONLY)) < 0) { X--- 315,321 ---- X struct linkbuf *lp; X X if ((lp = linkinfo(stb)) != NULL) X! return(sendhardlink(opts, lp, rname, destdir)); X } X X if ((f = open(target, O_RDONLY)) < 0) { X*************** X*** 365,371 **** X else if (f == 0 && IS_ON(opts, DO_COMPARE)) X return(0); X X! runspecial(target, opts); X X return(0); X } X--- 375,381 ---- X else if (f == 0 && IS_ON(opts, DO_COMPARE)) X return(0); X X! runspecial(target, opts, rname, destdir); X X return(0); X } X*************** X*** 444,452 **** X * Send a directory X */ X static int X! senddir(rname, opts, stb, user, group) X char *rname; X! int opts; X struct stat *stb; X char *user, *group; X { X--- 454,462 ---- X * Send a directory X */ X static int X! senddir(rname, opts, stb, user, group, destdir) X char *rname; X! int opts, destdir; X struct stat *stb; X char *user, *group; X { X*************** X*** 495,501 **** X while (*ptarget++ = *cp++) X ; X ptarget--; X! if (sendit(dp->d_name, opts) > 0) X didupdate = 1; X } X (void) closedir(d); X--- 505,511 ---- X while (*ptarget++ = *cp++) X ; X ptarget--; X! if (sendit(dp->d_name, opts, destdir) > 0) X didupdate = 1; X } X (void) closedir(d); X*************** X*** 513,521 **** X * Send a link X */ X static int X! sendlink(rname, opts, stb, user, group) X char *rname; X! int opts; X struct stat *stb; X char *user; X char *group; X--- 523,531 ---- X * Send a link X */ X static int X! sendlink(rname, opts, stb, user, group, destdir) X char *rname; X! int opts, destdir; X struct stat *stb; X char *user; X char *group; X*************** X*** 531,537 **** X struct linkbuf *lp; X X if ((lp = linkinfo(stb)) != NULL) X! return(sendhardlink(opts, lp, rname)); X } X X /* X--- 541,547 ---- X struct linkbuf *lp; X X if ((lp = linkinfo(stb)) != NULL) X! return(sendhardlink(opts, lp, rname, destdir)); X } X X /* X*************** X*** 584,590 **** X case C_END: /* End of send operation */ X *ptarget = CNULL; X ack(); X! runspecial(target, opts); X return(0); X X case C_LOGMSG: X--- 594,600 ---- X case C_END: /* End of send operation */ X *ptarget = CNULL; X ack(); X! runspecial(target, opts, rname, destdir); X return(0); X X case C_LOGMSG: X*************** X*** 895,903 **** X * Return > 0 if anything is updated. X */ X static int X! sendit(rname, opts) X char *rname; X! int opts; X { X static struct stat stb; X extern struct subcmd *subcmds; X--- 905,913 ---- X * Return > 0 if anything is updated. X */ X static int X! sendit(rname, opts, destdir) X char *rname; X! int opts, destdir; X { X static struct stat stb; X extern struct subcmd *subcmds; X*************** X*** 943,949 **** X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "%s: need to chmod to %o", target, X stb.st_mode & 07777); X! runspecial(target, opts); X return(1); X } X message(MT_CHANGE, "%s: chmod to %o", X--- 953,959 ---- X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "%s: need to chmod to %o", target, X stb.st_mode & 07777); X! runspecial(target, opts, rname, destdir); X return(1); X } X message(MT_CHANGE, "%s: chmod to %o", X*************** X*** 963,969 **** X if (u == US_NOENT) { X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "need to install: %s", target); X! runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X--- 973,979 ---- X if (u == US_NOENT) { X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "need to install: %s", target); X! runspecial(target, opts, rname, destdir); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X*************** X*** 976,982 **** X */ X switch (stb.st_mode & S_IFMT) { X case S_IFDIR: X! if (senddir(rname, opts, &stb, user, group) == 0) X didupdate = 1; X break; X X--- 986,992 ---- X */ X switch (stb.st_mode & S_IFMT) { X case S_IFDIR: X! if (senddir(rname, opts, &stb, user, group, destdir) == 0) X didupdate = 1; X break; X X*************** X*** 983,989 **** X case S_IFLNK: X if (u != US_NOENT) X FLAG_ON(opts, DO_COMPARE); X! if (sendlink(rname, opts, &stb, user, group) == 0) X didupdate = 1; X break; X X--- 993,999 ---- X case S_IFLNK: X if (u != US_NOENT) X FLAG_ON(opts, DO_COMPARE); X! if (sendlink(rname, opts, &stb, user, group, destdir) == 0) X didupdate = 1; X break; X X*************** X*** 991,1003 **** X if (u == US_OUTDATE) { X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "need to update: %s", target); X! runspecial(target, opts); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X message(MT_CHANGE, "updating: %s", target); X } X! if (sendfile(rname, opts, &stb, user, group) == 0) X didupdate = 1; X break; X X--- 1001,1013 ---- X if (u == US_OUTDATE) { X if (IS_ON(opts, DO_VERIFY)) { X message(MT_INFO, "need to update: %s", target); X! runspecial(target, opts, rname, destdir); X return(1); X } X if (!IS_ON(opts, DO_QUIET)) X message(MT_CHANGE, "updating: %s", target); X } X! if (sendfile(rname, opts, &stb, user, group, destdir) == 0) X didupdate = 1; X break; X X*************** X*** 1117,1123 **** X Tdest = destcopy; X } X X! didupdate = sendit(rname, opts); X Tdest = 0; X X return(didupdate); X--- 1127,1133 ---- X Tdest = destcopy; X } X X! didupdate = sendit(rname, opts, destdir); X Tdest = 0; X X return(didupdate); SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.defs.h && X*** 1.2 1993/02/19 06:52:25 X--- include/defs.h 1993/02/19 07:10:16 X*************** X*** 149,154 **** X--- 149,155 ---- X #define DO_REMOVE 0x000010 X #define DO_FOLLOW 0x000020 X #define DO_IGNLNKS 0x000040 X+ /* UNUSED 0x000080 */ X #define DO_QUIET 0x000100 X #define DO_CHKNFS 0x000200 X #define DO_CHKREADONLY 0x000400 X*************** X*** 156,165 **** X--- 157,171 ---- X #define DO_SAVETARGETS 0x001000 X #define DO_NODESCEND 0x002000 X #define DO_NOCHKOWNER 0x004000 X+ /* UNUSED 0x008000 */ X #define DO_NOCHKGROUP 0x010000 X #define DO_CHKSYM 0x020000 X #define DO_NUMCHKGROUP 0x040000 X #define DO_NUMCHKOWNER 0x080000 X+ #define DO_LOCALFILENAMES 0x100000 X+ /* UNUSED 0x200000 */ X+ /* UNUSED 0x400000 */ X+ /* UNUSED 0x800000 */ X X /* X * Dist option information X*************** X*** 229,237 **** X */ X #define E_FILES "FILES" X #define E_SFILE "FILE" /* local filenmae */ X! #define E_SRFILE "RFILE" /* Remove Filename */ X! #define E_SBFILE "BFILE" /* basename of FILE */ X! #define E_SBRFILE "BRFILE" /* basename of RFILE */ X X /* X * Suffix to use when saving files X--- 235,243 ---- X */ X #define E_FILES "FILES" X #define E_SFILE "FILE" /* local filenmae */ X! #define E_SLFILE "LOCALFILE" /* Local filename */ X! #define E_SRFILE "REMOTEFILE" /* Remote filename */ X! #define E_SBFILE "BASEFILE" /* basename of REMOTEFILE */ X X /* X * Suffix to use when saving files SHAR_EOF chmod 0644 patch.defs.h || echo "restore of patch.defs.h fails" sed 's/^X//' << 'SHAR_EOF' > patch.distopt.c && X*** 1.1 1993/02/19 07:05:36 X--- src/distopt.c 1993/02/19 07:06:20 X*************** X*** 70,75 **** X--- 70,76 ---- X { DO_NOCHKGROUP, "nochkgroup" }, X { DO_NUMCHKGROUP, "numchkgroup" }, X { DO_NUMCHKOWNER, "numchkowner" }, X+ { DO_LOCALFILENAMES, "localfilenames" }, X { 0 }, X }; X SHAR_EOF chmod 0644 patch.distopt.c || echo "restore of patch.distopt.c fails" exit 0 From rsalz@osf.org Fri Feb 19 05:09:04 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08903; Fri, 19 Feb 93 05:09:04 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22327; Fri, 19 Feb 93 08:09:00 -0500 Received: by earth.osf.org (5.65/4.7) id AA06023; Fri, 19 Feb 93 08:08:59 -0500 Date: Fri, 19 Feb 93 08:08:59 -0500 From: rsalz@osf.org Message-Id: <9302191308.AA06023@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu > I have a better idea. How about just $FILE and $BASEFILE? Then we can have > an option that determines what $FILE returns (local or remote name, with the > default the remote name). How about -ofile=local or something like that? That is a real bad idea. Fixed variable names should have fixed meanings; you should not be able to shuffle around what a variable does based on some silly little -o flag. /r$ From rsalz@osf.org Fri Feb 19 05:10:41 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08954; Fri, 19 Feb 93 05:10:41 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22376; Fri, 19 Feb 93 08:10:39 -0500 Received: by earth.osf.org (5.65/4.7) id AA06035; Fri, 19 Feb 93 08:10:37 -0500 Date: Fri, 19 Feb 93 08:10:37 -0500 From: rsalz@osf.org Message-Id: <9302191310.AA06035@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu > Currently, the log format is: > : : <"updating"|"installing"|"need to .."> > This should be changed to: > : <"updating"|"installing"|"need to ..">: I disagree. The advantage of the current format is that you can parse it more easily with Unix tools such as awk and perl. /r$ From rsalz@osf.org Fri Feb 19 05:11:27 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08959; Fri, 19 Feb 93 05:11:27 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22410; Fri, 19 Feb 93 08:11:25 -0500 Received: by earth.osf.org (5.65/4.7) id AA06058; Fri, 19 Feb 93 08:11:23 -0500 Date: Fri, 19 Feb 93 08:11:23 -0500 From: rsalz@osf.org Message-Id: <9302191311.AA06058@earth.osf.org> To: dbeusee@us.oracle.com, matt@aodc20.aodc.gov.au, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu > Wouldn't .. > ::: > be nice? Only if you want to disallow colons in filenames. From wls@astro.UMD.EDU Fri Feb 19 07:27:15 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13392; Fri, 19 Feb 93 07:27:15 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA24722; Fri, 19 Feb 1993 10:27:13 -0500 Date: Fri, 19 Feb 1993 10:27:13 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302191527.AA24722@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: Bug in freespace code. "John P. Rouillard" says: > After two hours of work, I just figured out one of the basic rules of > divison. Under some OS's like Irix, the size of a block < 1024. So > the line of code in getfilesysinfo() that reads: > > *freespace = statfsbuf.f_bavail * (statfsbuf.f_bsize / 1024) > > always assigns 0 to *freespace, since it is obvious to the reader that > 512/1024 = 0. The fix I used was to explicitly cast statfsbuf.f_bsize > to double. So the code now reads: > > *freespace = statfsbuf.f_bavail * ((double) statfsbuf.f_bsize / 1024) *freespace = (statfsbuf.f_bavail * (unsigned long)statfsbuf.f_bsize) / 1024 would be better if the one did not want to introduce floating point arithmetic into rdist (which I believe there is none now) and if filesystems were smaller than 4 GB. Since that file system size assumption may soon be dubious and since I think that the smallest block size in a Unix system and likely block size on the IRIX is 512 (512 was the original traditional Unix block size) the statement: *freespace = (statfsbuf.f_bavail * (statfsbuf.f_bsize / 512)) / 2 would be adequate. Probably to cover all bases you would have to use floating point. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Fri Feb 19 07:37:17 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13585; Fri, 19 Feb 93 07:37:17 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA24836; Fri, 19 Feb 1993 10:34:33 -0500 Date: Fri, 19 Feb 1993 10:34:33 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199302191534.AA24836@lynx.astro.umd.edu> To: dbeusee@us.oracle.com Subject: Re: list awkwardness Cc: rdist-dev@usc.edu > I am not proposing (and in fact am against it because it is dangerous) for > rdist to wipe out a directory with a plain file. I think the current safety > feature to return an error if local is a file and remote is a directory > (empty or not). > > I am only proposing that an option like -odirectory (actually I like -odestdir > better) be used to indicate that the destination is a directory and that the > file should be put in that directory, so that the following would work: > file -> host > install -odestdir remdir; > > This allows the following to work as well (which matches your scenerio): > ((file1 file2) - file2) -> host > install -odestdir remdir; I still disagree that the option should be required but I guess I could very reluctantly live with it. What I couldn't live with (and I think would be a disaster) would be if there was more than one file on the list and the option was not given that it would assume that the destination path was not a directory. I guess I am trying to point out the inconsistancy where there is more than one file on the list the destination is assumed to be a directory but when there is one file on the list the destination is assumed to be a file. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From mcooper@ucs.usc.edu Fri Feb 19 10:05:33 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18722; Fri, 19 Feb 93 10:05:33 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA06326; Fri, 19 Feb 93 10:05:10 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 10:05:10 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Thu, 18 Feb 93 22:43:38 PST Message-Id: I think that you really do want to always have the filename printed, so that you know the context of the error. e.g. If you are installing /usr/bin/login, you really do want to know that "root" is an unknown user and that the setuid bit is being stripped. mike From mcooper@ucs.usc.edu Fri Feb 19 10:09:10 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18934; Fri, 19 Feb 93 10:09:10 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA06342; Fri, 19 Feb 93 10:08:46 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 10:08:46 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: matt@aodc20.aodc.gov.au (Matthew Hannigan) Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Fri, 19 Feb 93 18:52:21 -0500 Message-Id: File names get very long, so you really don't want both the local and remote names. mike From mcooper@ucs.usc.edu Fri Feb 19 10:16:28 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19197; Fri, 19 Feb 93 10:16:28 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA06390; Fri, 19 Feb 93 10:16:11 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 10:16:10 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rsalz@osf.org Cc: dbeusee@us.oracle.com, matt@aodc20.aodc.gov.au, rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Fri, 19 Feb 93 08:11:23 -0500 Message-Id: Rich does have a point. *I* do have files with colons in them. If you ever want to parse the output, then I think the filenames have to always be last. mike From dbeusee@us.oracle.com Fri Feb 19 13:12:43 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26111; Fri, 19 Feb 93 13:12:43 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA13817; Fri, 19 Feb 93 13:12:15 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04060; Fri, 19 Feb 93 12:59:28 PST Message-Id: <9302192059.AA04060@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 12:59:28 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu The new format does not make it any more difficult. It is just switching the args at the benifit of readability. From rsalz@osf.org Fri Feb 19 05:05:26 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03226; Fri, 19 Feb 93 05:05:24 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA22858; Fri, 19 Feb 93 05:11:56 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22376; Fri, 19 Feb 93 08:10:39 -0500 Received: by earth.osf.org (5.65/4.7) id AA06035; Fri, 19 Feb 93 08:10:37 -0500 Date: Fri, 19 Feb 93 08:10:37 -0500 From: rsalz@osf.org Message-Id: <9302191310.AA06035@earth.osf.org> To: dbeusee@us, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Status: R > Currently, the log format is: > : : <"updating"|"installing"|"need to .."> > This should be changed to: > : <"updating"|"installing"|"need to ..">: I disagree. The advantage of the current format is that you can parse it more easily with Unix tools such as awk and perl. /r$ From dbeusee@us.oracle.com Fri Feb 19 13:14:30 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26190; Fri, 19 Feb 93 13:14:30 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA14025; Fri, 19 Feb 93 13:14:26 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04097; Fri, 19 Feb 93 13:07:50 PST Message-Id: <9302192107.AA04097@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 13:07:50 PST From: Don Beusee To: mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu The filename is already logged on the previous line (updating: ...). No need to include it on the next line too when it has nothing to do with the file. From mcooper@skat.usc.edu Fri Feb 19 10:01:38 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03758; Fri, 19 Feb 93 10:01:37 PST Received: from skat.usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA04573; Fri, 19 Feb 93 10:08:05 PST Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA01813; Fri, 19 Feb 93 10:05:10 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA06326; Fri, 19 Feb 93 10:05:10 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 10:05:10 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Thu, 18 Feb 93 22:43:38 PST Message-Id: Status: R I think that you really do want to always have the filename printed, so that you know the context of the error. e.g. If you are installing /usr/bin/login, you really do want to know that "root" is an unknown user and that the setuid bit is being stripped. mike From dbeusee@us.oracle.com Fri Feb 19 13:15:11 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26201; Fri, 19 Feb 93 13:15:11 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA14059; Fri, 19 Feb 93 13:15:07 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04108; Fri, 19 Feb 93 13:08:32 PST Message-Id: <9302192108.AA04108@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 13:08:32 PST From: Don Beusee To: matt@aodc20.aodc.gov.au, mcooper@usc.edu Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu except with an option would be nice. From mcooper@skat.usc.edu Fri Feb 19 10:05:12 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03771; Fri, 19 Feb 93 10:05:11 PST Received: from skat.usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA04768; Fri, 19 Feb 93 10:11:41 PST Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA02315; Fri, 19 Feb 93 10:08:49 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA06342; Fri, 19 Feb 93 10:08:46 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 10:08:46 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: matt@aodc20.aodc.gov.au (Matthew Hannigan) Cc: dbeusee@us, rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Fri, 19 Feb 93 18:52:21 -0500 Message-Id: Status: R File names get very long, so you really don't want both the local and remote names. mike From mcooper@ucs.usc.edu Fri Feb 19 13:56:43 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27566; Fri, 19 Feb 93 13:56:43 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA01764; Fri, 19 Feb 93 13:56:39 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 13:56:39 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Fri, 19 Feb 93 13:07:50 PST Message-Id: > The filename is already logged on the previous line (updating: ...). No need > to include it on the next line too when it has nothing to do with the file. > > >From mcooper@skat.usc.edu Fri Feb 19 10:01:38 1993 > Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) > id AA03758; Fri, 19 Feb 93 10:01:37 PST > Received: from skat.usc.edu by gatekeeper.oracle.com (5.59.11/37.7) > id AA04573; Fri, 19 Feb 93 10:08:05 PST > Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.5) > id AA01813; Fri, 19 Feb 93 10:05:10 PST > Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) > id AA06326; Fri, 19 Feb 93 10:05:10 PST > Sender: "Michael A. Cooper" > Date: Fri, 19 Feb 93 10:05:10 PST > From: Michael A. Cooper > Reply-To: mcooper@usc.edu > To: Don Beusee > Cc: rdist-dev@usc.edu > Subject: Re: comments on rdist log format > In-Reply-To: Your message of Thu, 18 Feb 93 22:43:38 PST > Message-Id: > Status: R > > I think that you really do want to always have the filename printed, > so that you know the context of the error. e.g. If you are installing > /usr/bin/login, you really do want to know that "root" is an unknown > user and that the setuid bit is being stripped. > > mike > > Not true if you use a filter program that likes to sort things. mike From rsalz@osf.org Fri Feb 19 14:08:10 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28079; Fri, 19 Feb 93 14:08:10 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA25955; Fri, 19 Feb 93 17:08:06 -0500 Received: by earth.osf.org (5.65/4.7) id AA07747; Fri, 19 Feb 93 17:08:04 -0500 Date: Fri, 19 Feb 93 17:08:04 -0500 From: rsalz@osf.org Message-Id: <9302192208.AA07747@earth.osf.org> To: dbeusee@us.oracle.com, mcooper@usc.edu, rsalz@osf.org Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu > The new format does not make it any more difficult. It is just switching the > args at the benifit of readability. Oh really? Right now I can use (assuming I am feeding the script into awk or perl) $1 and $2 trivially; putting variable-length (in terms of number of fields, not number of characters) data in the middle of the line means I have to do things like $NF which is okay for awk, but a real pain for things like sed. /r$ From dbeusee@us.oracle.com Fri Feb 19 14:40:08 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29139; Fri, 19 Feb 93 14:40:08 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA13479; Fri, 19 Feb 93 13:05:07 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04057; Fri, 19 Feb 93 12:58:10 PST Message-Id: <9302192058.AA04057@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 12:58:10 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Thats what options are for - to get backward compatibility if you want it, but still allowing us to move forward on new functionality. From rsalz@osf.org Fri Feb 19 05:03:38 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03116; Fri, 19 Feb 93 05:03:36 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA22842; Fri, 19 Feb 93 05:10:07 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22327; Fri, 19 Feb 93 08:09:00 -0500 Received: by earth.osf.org (5.65/4.7) id AA06023; Fri, 19 Feb 93 08:08:59 -0500 Date: Fri, 19 Feb 93 08:08:59 -0500 From: rsalz@osf.org Message-Id: <9302191308.AA06023@earth.osf.org> To: dbeusee@us, mcooper@usc.edu, rsalz@osf.org Subject: Re: small enhancement patch Cc: rdist-dev@usc.edu Status: R > I have a better idea. How about just $FILE and $BASEFILE? Then we can have > an option that determines what $FILE returns (local or remote name, with the > default the remote name). How about -ofile=local or something like that? That is a real bad idea. Fixed variable names should have fixed meanings; you should not be able to shuffle around what a variable does based on some silly little -o flag. /r$ From dbeusee@us.oracle.com Fri Feb 19 14:39:11 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29128; Fri, 19 Feb 93 14:39:11 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA17708; Fri, 19 Feb 93 14:39:02 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04293; Fri, 19 Feb 93 14:32:22 PST Message-Id: <9302192232.AA04293@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 14:32:22 PST From: Don Beusee To: mcooper@usc.edu Subject: patch to server.c to put filename back in messages Cc: rdist-dev@usc.edu The only sort that should be done is: sort +0 -1 To get it in hostname order. Any other sorting is invalid in terms of order of events, which is important regardless if the messages all contain the filename or not. But your argument is valid, since the mode is changed on the file. For that reason, I agree the filename should be in the message. I changed it to be like this: : REMOTE WARNING: unknown login name "", clearing setuid on Here is the diff patch for this change to server.c: *** 1.2 1993/02/19 06:51:27 --- src/server.c 1993/02/19 22:25:00 *************** *** 32,38 **** */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 1.2 1993/02/19 06:51:27 dbeusee Exp dbeusee $"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; --- 32,38 ---- */ #ifndef lint static char RCSid[] = ! "$Id: server.c,v 1.2 1993/02/19 06:51:27 dbeusee Exp $"; static char sccsid[] = "@(#)server.c 5.3 (Berkeley) 6/7/86"; *************** *** 165,172 **** if ((pw = getpwnam(owner)) == NULL) { if (IS_ON(mode, S_ISUID)) { message(MT_NOTICE, ! "REMOTE WARNING: unknown login name \"%s\", clearing setuid", ! owner); mode &= ~S_ISUID; uid = 0; } else --- 165,172 ---- if ((pw = getpwnam(owner)) == NULL) { if (IS_ON(mode, S_ISUID)) { message(MT_NOTICE, ! "REMOTE WARNING: unknown login name \"%s\", clearing setuid on %s", ! owner, file); mode &= ~S_ISUID; uid = 0; } else *************** *** 202,209 **** || ((gr = getgrnam(group)) == NULL)) { if (IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: unknown group \"%s\", clearing setgid", ! group); mode &= ~S_ISGID; } else message(MT_NOTICE, --- 202,209 ---- || ((gr = getgrnam(group)) == NULL)) { if (IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: unknown group \"%s\", clearing setgid on %s", ! group, file); mode &= ~S_ISGID; } else message(MT_NOTICE, *************** *** 221,228 **** goto ok; if (mode != -1 && IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: user %s not in group %s, clearing setgid", ! locuser, group); mode &= ~S_ISGID; } gid = -1; --- 221,228 ---- goto ok; if (mode != -1 && IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: user %s not in group %s, clearing setgid on %s", ! locuser, group, file); mode &= ~S_ISGID; } gid = -1; *************** *** 236,247 **** if (setownership(file, fd, uid, gid) < 0) { if (mode != -1 && IS_ON(mode, S_ISUID)) { message(MT_NOTICE, ! "REMOTE WARNING: chown failed, clearing setuid"); mode &= ~S_ISUID; } if (mode != -1 && IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: chown failed, clearing setgid"); mode &= ~S_ISGID; } } --- 236,249 ---- if (setownership(file, fd, uid, gid) < 0) { if (mode != -1 && IS_ON(mode, S_ISUID)) { message(MT_NOTICE, ! "REMOTE WARNING: chown failed, clearing setuid on %s", ! file); mode &= ~S_ISUID; } if (mode != -1 && IS_ON(mode, S_ISGID)) { message(MT_NOTICE, ! "REMOTE WARNING: chown failed, clearing setgid on %s", ! file); mode &= ~S_ISGID; } } From dbeusee@us.oracle.com Fri Feb 19 15:10:42 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00609; Fri, 19 Feb 93 15:10:42 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA19124; Fri, 19 Feb 93 15:10:17 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04377; Fri, 19 Feb 93 15:03:40 PST Message-Id: <9302192303.AA04377@dbeusee.us.oracle.com> Date: Fri, 19 Feb 93 15:03:40 PST From: Don Beusee To: mcooper@usc.edu, rsalz@osf.org Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Well, I think awk is the right tool anyway, but sed can get the last arg: egrep 'updating:|installing:' rdist.log | sed 's/.* //' | sort | uniq This gives a list of files installed. Do we agree that the filename should be last since filenames can have ':'s in them? Also, you might want to include local and remote filenames. Maybe we can only make everyone happy if we can define the format of messages. Maybe something like: -ologformat='%host: %text: %remotefile' (default format) Then if someone wants to get fancy, they can do: -ologformat='%host|%text|%localfile|%remotefile' Hows that idea? Also, I think there should be an environment variable for another way to specify rdist options: setenv RDISTOPTS \ '-ochkreadonly,ologformat=%host|%text|%localfile|%remotefile -t 300' Would be really cool. It should work as if you did: rdist $RDISTOPTS ... Regards, Don. From rsalz@osf.org Fri Feb 19 14:02:51 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04249; Fri, 19 Feb 93 14:02:50 PST Received: from postman.osf.org by gatekeeper.oracle.com (5.59.11/37.7) id AA16615; Fri, 19 Feb 93 14:09:18 PST Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA25955; Fri, 19 Feb 93 17:08:06 -0500 Received: by earth.osf.org (5.65/4.7) id AA07747; Fri, 19 Feb 93 17:08:04 -0500 Date: Fri, 19 Feb 93 17:08:04 -0500 From: rsalz@osf.org Message-Id: <9302192208.AA07747@earth.osf.org> To: dbeusee@us, mcooper@usc.edu, rsalz@osf.org Subject: Re: comments on rdist log format Cc: rdist-dev@usc.edu Status: R > The new format does not make it any more difficult. It is just switching the > args at the benifit of readability. Oh really? Right now I can use (assuming I am feeding the script into awk or perl) $1 and $2 trivially; putting variable-length (in terms of number of fields, not number of characters) data in the middle of the line means I have to do things like $NF which is okay for awk, but a real pain for things like sed. /r$ From mcooper@ucs.usc.edu Fri Feb 19 15:50:24 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02114; Fri, 19 Feb 93 15:50:24 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA02787; Fri, 19 Feb 93 15:50:18 PST Sender: "Michael A. Cooper" Date: Fri, 19 Feb 93 15:50:17 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rsalz@osf.org, rdist-dev@usc.edu Subject: Re: comments on rdist log format In-Reply-To: Your message of Fri, 19 Feb 93 15:03:40 PST Message-Id: Sounds reasonable to me. mike From rouilj@cs.umb.edu Sun Feb 21 01:17:52 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03232; Sun, 21 Feb 93 01:17:52 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA19937 (5.65c/IDA-1.4.4 for ); Fri, 19 Feb 1993 22:19:01 -0500 Message-Id: <199302200319.AA19937@cs.umb.edu> To: rdist-dev@usc.edu Subject: What does free space mean? Date: Fri, 19 Feb 1993 22:19:01 -0500 From: "John P. Rouillard" In doing my Sinix and SVR4 port's, I am faced with a dilemma. What does (the "-a" parameter") free space mean? Is it usable freespace by non-root users, or the total space available? (A similar question could be asked for inodes.) In the case of ultrix, it is usable free space, which is what is often reported by utilities such as df, in the available space category. In the STATFS_SYSV (and maybe AIX) case, it is the total number of free blocks. However, in the other cases f_bavail provides the user freespace. This leads to a problem: How do we determine which way the interpretation is to occur. I am leaning to always using the amount of freespace available for root, since I can just increment the value I use for the -a parameter. This does make (the usual case I believe) reserving a certain number of user bytes somewhat tougher. However, this option does allow me to use all available user space and then some. I am not sure if the split can be between user and root filespace is available on all systems, and I want something consistant across all rdist platforms. There are few things worse than having to guess how rdistd will interpret the freespace parameters. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From mcooper@ucs.usc.edu Sun Feb 21 10:54:56 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15990; Sun, 21 Feb 93 10:54:56 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA12334; Sun, 21 Feb 93 10:54:55 PST Sender: "Michael A. Cooper" Date: Sun, 21 Feb 93 10:54:54 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "John P. Rouillard" Cc: rdist-dev@usc.edu Subject: Re: What does free space mean? In-Reply-To: Your message of Fri, 19 Feb 1993 22:19:01 -0500 Message-Id: My feeling is that it should be the user free space since that is consistant whether you are a normal user or root. You shouldn't have your filesystems that full anyway. :-) mike From aad@lovecraft.siemens.com Sun Feb 21 12:43:30 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18770; Sun, 21 Feb 93 12:43:30 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nQNWK-0019D9C; Sun, 21 Feb 93 15:43 EST Received: by lovecraft (4.1/SMI-4.1) id AA08073; Sun, 21 Feb 93 15:43:25 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Sun, 21 Feb 1993 15:43:25 -0500 (EST) Message-Id: Date: Sun, 21 Feb 1993 15:43:25 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: should cmdspecial always be done? I'm running 6.1 sans patches on Sun 4c's from 4.1.1 to 4.1.3, bundled compiler. Now that cmdspecials are logged, I've noticed that they're executed even if no file in the associated package is updated. Is this the way that it shold be? This behavior is sometimes genuinely useful, but I don't want to count on it if it's inadvertant. The relevent section of the man page seems vague about this point: The cmdspecial command is similar to the special command, except it is executed only when the entire command is com- pleted instead of after each file is updated. The list of files is placed in the environment variable $FILES. Each file name in $FILES is separated by a `:' (semi-colon). ======================================================================8--< From dbeusee@us.oracle.com Sun Feb 21 16:02:39 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23927; Sun, 21 Feb 93 16:02:39 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA02132; Sun, 21 Feb 93 16:02:30 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09032; Sun, 21 Feb 93 15:55:57 PST Message-Id: <9302212355.AA09032@dbeusee.us.oracle.com> Date: Sun, 21 Feb 93 15:55:57 PST From: Don Beusee To: rdist-dev@usc.edu, rouilj@ra.cs.umb.edu Subject: Re: What does free space mean? Any platform that has both should take the current uid value to determine which value to use. If uid=0 (root), then it should use root's value, otherwise use the value for non-root users. Does this freespace thing acount for the files that are already there? If the files you are rdist'ing are there except for a few of them, and you have space for those files, but not the entire set, will the rdist proceed? From rouilj@cs.umb.edu Sun Feb 21 01:33:54 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07844; Sun, 21 Feb 93 01:33:52 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA21589; Sun, 21 Feb 93 01:40:21 PST Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03232; Sun, 21 Feb 93 01:17:52 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA19937 (5.65c/IDA-1.4.4 for ); Fri, 19 Feb 1993 22:19:01 -0500 Message-Id: <199302200319.AA19937@cs.umb.edu> To: rdist-dev@usc.edu Subject: What does free space mean? Date: Fri, 19 Feb 1993 22:19:01 -0500 From: "John P. Rouillard" Status: R In doing my Sinix and SVR4 port's, I am faced with a dilemma. What does (the "-a" parameter") free space mean? Is it usable freespace by non-root users, or the total space available? (A similar question could be asked for inodes.) In the case of ultrix, it is usable free space, which is what is often reported by utilities such as df, in the available space category. In the STATFS_SYSV (and maybe AIX) case, it is the total number of free blocks. However, in the other cases f_bavail provides the user freespace. This leads to a problem: How do we determine which way the interpretation is to occur. I am leaning to always using the amount of freespace available for root, since I can just increment the value I use for the -a parameter. This does make (the usual case I believe) reserving a certain number of user bytes somewhat tougher. However, this option does allow me to use all available user space and then some. I am not sure if the split can be between user and root filespace is available on all systems, and I want something consistant across all rdist platforms. There are few things worse than having to guess how rdistd will interpret the freespace parameters. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Sun Feb 21 17:31:50 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26350; Sun, 21 Feb 93 17:31:50 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA03290; Sun, 21 Feb 93 17:20:14 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09196; Sun, 21 Feb 93 17:13:37 PST Message-Id: <9302220113.AA09196@dbeusee.us.oracle.com> Date: Sun, 21 Feb 93 17:13:37 PST From: Don Beusee To: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: should cmdspecial always be done? I think it should always be done. The script or command can check if any files were updated by checking the "$FILES" variable. My patch is useful because it sticks it in the environment so that a script could have access to it. I would like to see some additional special directives: prespecial "..."; (executed before updating any files) prelocal "..."; (executed on local system before updating any files) cmdlocal "..."; (executed on local system after updating all files) The local ones are good for rdist'ing other dependant packages that are rdist'd by a different command: cmdlocal "cd ../otherpackage; rdist -f package.rdist"; prespecial is good for making sure the remote directory is setup properly (possibly symlinked to the correct partition, etc). All these commands should always be done (regardless if anyt file are updated). Maybe a couple of other enhancements for the distfile would be: include "common.rdist"; (this should be able to appear at any point in the distfile (outside the -> directive)) localcmd "local command"; (execute command on local system) Maybe the prelocal and cmdlocal are not needed if the localcmd is executed in the order it appears: sample distfile: localcmd "do before anything"; filea -> hosta localcmd "do before filea"; install; localcmd "do after filea"; fileb -> hostb localcmd "do after fileb"; host "do after everything above"; include "another.rdist"; ================================================================ The problem here is, how do you know the last localcmd is not part of the fileb update? It would be nice if rdist had a way to "block" things together: ================================================================ filea -> hosta { localcmd "do before filea"; install; localcmd "do after filea"; } fileb -> hostb { localcmd "do after fileb"; } packageb: { localcmd "do before any packageb stuff"; filec -> hostc install; filed -> hostd install; localcmd "do after all packageb stuff"; } localcmd "do after everything above"; ================================================================ Regards, Don. From aad@lovecraft.siemens.com Sun Feb 21 13:01:32 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08867; Sun, 21 Feb 93 13:01:31 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA29664; Sun, 21 Feb 93 13:08:01 PST Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18770; Sun, 21 Feb 93 12:43:30 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nQNWK-0019D9C; Sun, 21 Feb 93 15:43 EST Received: by lovecraft (4.1/SMI-4.1) id AA08073; Sun, 21 Feb 93 15:43:25 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Sun, 21 Feb 1993 15:43:25 -0500 (EST) Message-Id: Date: Sun, 21 Feb 1993 15:43:25 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: should cmdspecial always be done? Status: R I'm running 6.1 sans patches on Sun 4c's from 4.1.1 to 4.1.3, bundled compiler. Now that cmdspecials are logged, I've noticed that they're executed even if no file in the associated package is updated. Is this the way that it shold be? This behavior is sometimes genuinely useful, but I don't want to count on it if it's inadvertant. The relevent section of the man page seems vague about this point: The cmdspecial command is similar to the special command, except it is executed only when the entire command is com- pleted instead of after each file is updated. The list of files is placed in the environment variable $FILES. Each file name in $FILES is separated by a `:' (semi-colon). ======================================================================8--< From dbeusee@us.oracle.com Mon Feb 22 01:28:18 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09527; Mon, 22 Feb 93 01:28:18 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA10639; Mon, 22 Feb 93 01:28:14 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10411; Mon, 22 Feb 93 01:21:39 PST Message-Id: <9302220921.AA10411@dbeusee.us.oracle.com> Date: Mon, 22 Feb 93 01:21:39 PST From: Don Beusee To: mcooper@usc.edu Subject: patch for "updating host" to non-debug message Cc: rdist-dev@usc.edu I just noticed that the "updating host" messages were showing up as DEBUG messages. This patch fixes that: This is the diff for src/docmd.c: *** 1.3 1993/02/22 09:23:52 --- src/docmd.c 1993/02/22 09:25:03 *************** *** 276,282 **** ruser = locuser; if (!IS_ON(options, DO_QUIET)) ! message(MT_INFO|MT_DEBUG, "updating host %s", rhost); (void) sprintf(buf, "%s -S", _PATH_RDISTD); --- 276,282 ---- ruser = locuser; if (!IS_ON(options, DO_QUIET)) ! message(MT_INFO, "updating host %s", rhost); (void) sprintf(buf, "%s -S", _PATH_RDISTD); From dbeusee@us.oracle.com Mon Feb 22 01:31:56 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09564; Mon, 22 Feb 93 01:31:56 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA10538; Mon, 22 Feb 93 01:20:01 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10404; Mon, 22 Feb 93 01:13:27 PST Message-Id: <9302220913.AA10404@dbeusee.us.oracle.com> Date: Mon, 22 Feb 93 01:13:27 PST From: Don Beusee To: mcooper@usc.edu Subject: another rdist patch (hardlink, destdir, debugmsg) Cc: rdist-dev@usc.edu This patch contains the following fixes: 1) destdir flag was zero when using the following syntax: dir -> hosta install /tmp; with this patch, if only one file specified before -> and that file is a directory, then the target is also assumed to be a directory (set destdir=1). 2) last hardlink patch caused bug where remfilename() routine wrote over the dest pathname when destdir=1. Fixes 1 and 2 allow the FILE variables to get set correctly. 3) if destination filename is specified as dir/. then it is assumed to be a directory (even if only one file is specified before ->), as in the following example: (file) -> hosta install /tmp/.; 4) debug messages now have DEBUG: in the message so that they can be parsed out of the rdist log. Here is the shar file containing the diffs... #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.docmd.c # patch.message.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.5 1993/02/19 09:42:42 X--- src/client.c 1993/02/22 08:50:57 X*************** X*** 92,107 **** X debugmsg(DM_MISC, X "remfilename: src=%s, dest=%s, path=%s, rname=%s, destdir=%d\n", X src, dest, path, rname, destdir); X if (path && *path) { X! lname = strrchr(path, '/'); X! if ((lname == NULL) || (path && *path == '/')) { X! lname = path; X if (destdir) { X strcat(lname, "/"); X strcat(lname, rname); X } X } else { X! lname = cp = buff; X strcpy(cp, dest); X cp += strlen(cp); X while (*src) { X--- 92,108 ---- X debugmsg(DM_MISC, X "remfilename: src=%s, dest=%s, path=%s, rname=%s, destdir=%d\n", X src, dest, path, rname, destdir); X+ lname = buff; X if (path && *path) { X! cp = strrchr(path, '/'); X! if ((cp == NULL) || (path && *path == '/')) { X! strcpy(lname, path); X if (destdir) { X strcat(lname, "/"); X strcat(lname, rname); X } X } else { X! cp = buff; X strcpy(cp, dest); X cp += strlen(cp); X while (*src) { X*************** X*** 116,122 **** X } X } X } else { X- lname = buff; X strcpy(lname, dest); X } X debugmsg(DM_MISC, "remfilename: remote filename=%s\n", lname); X--- 117,122 ---- X*************** X*** 1068,1076 **** X char *cp; X X cp = getondistoptlist(opts); X! (void) printf("%s%s%s %s %s\n", X IS_ON(opts, DO_VERIFY) ? "verify" : "install", X! (cp) ? " -o" : "", (cp) ? cp : "", X src, dest); X if (nflag) X return(0); X--- 1068,1082 ---- X char *cp; X X cp = getondistoptlist(opts); X! if (!nflag) X! (void) debugmsg(DM_MISC, "%s%s%s %s %s\n", X IS_ON(opts, DO_VERIFY) ? "verify" : "install", X! (cp && *cp) ? " -o" : "", (cp) ? cp : "", X! src, dest); X! else X! (void) printf("%s%s%s %s %s\n", X! IS_ON(opts, DO_VERIFY) ? "verify" : "install", X! (cp && *cp) ? " -o" : "", (cp) ? cp : "", X src, dest); X if (nflag) X return(0); SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.docmd.c && X*** 1.2 1993/02/19 06:07:40 X--- src/docmd.c 1993/02/22 07:51:00 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: docmd.c,v 1.2 1993/02/19 06:07:40 dbeusee Exp dbeusee $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! "$Id: docmd.c,v 1.2 1993/02/19 06:07:40 dbeusee Exp $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X*************** X*** 62,67 **** X--- 62,69 ---- X extern int maxchildren; X extern int amchild; X X+ extern char *basename(); X+ X static void cmptime(); X X /* X*************** X*** 394,400 **** X--- 396,416 ---- X } X X subcmds = sbcmds; X+ /* X+ * destination is a directory if one of the following is true: X+ * a) more than one name specified on left side of -> directive X+ * b) basename of destination in "install" directive is "." X+ * (e.g. install /tmp/.;) X+ * c) name on left side of -> directive is a directory on local system. X+ */ X ddir = files->n_next != NULL; /* destination is a directory */ X+ if (!ddir && sbcmds->sc_name && *sbcmds->sc_name) X+ ddir = !strcmp(basename(sbcmds->sc_name),"."); X+ if (!ddir) { X+ struct stat s; X+ if (lstat(files->n_name, &s) == 0) X+ ddir = S_ISDIR(s.st_mode); X+ } X if (nflag) X (void) printf("updating host %s\n", rhost); X else { SHAR_EOF chmod 0644 patch.docmd.c || echo "restore of patch.docmd.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.message.c && X*** 1.3 1993/02/19 06:51:19 X--- src/message.c 1993/02/22 08:32:20 X*************** X*** 501,506 **** X--- 501,510 ---- X (void) sprintf(buf, "%s:", currenthost); X (void) sprintf(mbuf, "%-10s", buf); /* pad to 10 bytes */ X } X+ X+ if (IS_ON(flags, MT_DEBUG)) X+ strcat(mbuf, "DEBUG: "); X+ X (void) strcat(mbuf, msgbuf); X X /* SHAR_EOF chmod 0644 patch.message.c || echo "restore of patch.message.c fails" exit 0 From mcooper@ucs.usc.edu Mon Feb 22 10:05:27 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24045; Mon, 22 Feb 93 10:05:27 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA14305; Mon, 22 Feb 93 10:05:08 PST Sender: "Michael A. Cooper" Date: Mon, 22 Feb 93 10:05:07 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu, rouilj@ra.cs.umb.edu Subject: Re: What does free space mean? In-Reply-To: Your message of Sun, 21 Feb 93 15:55:57 PST Message-Id: The freespace checking takes into account the size of the file to be sent to the remote host. No provision is made for groups of files, since rdist doesn't really group files together internally. mike From mcooper@ucs.usc.edu Mon Feb 22 10:10:48 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24198; Mon, 22 Feb 93 10:10:48 PST Received: by acamar.usc.edu (4.1/SMI-4.1+ucs-3.5) id AA14330; Mon, 22 Feb 93 10:10:44 PST Sender: "Michael A. Cooper" Date: Mon, 22 Feb 93 10:10:43 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: should cmdspecial always be done? In-Reply-To: Your message of Sun, 21 Feb 93 17:13:37 PST Message-Id: The "prespecial", "prelocal", and "cmdlocal" sound reasonable. I'm not sure of the use of cmdlocal outside of the normal rules. "include" is not needed since you can use a preprocessor like m4 or cpp and tell rdist to read the distfile from stdin with "-f -". The chances of seeing these new commands soon is pretty low due to my workload. Of course, if somebody contributes the code... :-) mike From aad@lovecraft.siemens.com Tue Feb 23 14:07:18 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21662; Tue, 23 Feb 93 14:07:18 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nR7mU-0019DjC; Tue, 23 Feb 93 17:07 EST Received: by lovecraft (4.1/SMI-4.1) id AA11930; Tue, 23 Feb 93 17:07:14 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Tue, 23 Feb 1993 17:07:14 -0500 (EST) Message-Id: Date: Tue, 23 Feb 1993 17:07:14 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: 6.1 and setreuid? I'm running 6.1, Sun 4c's, SunOS 4.1.[13], bundled compiler. Running rdist as a normal user gives <=>lovecraft<=>rdist lovecraft: local error: setreuid(0, 838) failed: Not owner. The error goes away if I setuid rdist -- is this to be expected? ======================================================================8--< From mcooper@ucs.usc.edu Tue Feb 23 14:48:06 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23203; Tue, 23 Feb 93 14:48:06 PST Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA06041; Tue, 23 Feb 93 14:48:03 PST Sender: "Michael A. Cooper" Date: Tue, 23 Feb 93 14:48:02 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "Anthony A. Datri" Cc: rdist-dev@usc.edu Subject: Re: 6.1 and setreuid? In-Reply-To: Your message of Tue, 23 Feb 1993 17:07:14 -0500 (EST) Message-Id: Content-Length: 97 Yes, the rdist program must be setuid root. The src/Makefile should install it that way. mike From aad@lovecraft Wed Feb 24 15:37:42 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15701; Wed, 24 Feb 93 15:37:42 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nRVfY-0019LDC; Wed, 24 Feb 93 18:37 EST Received: by lovecraft (4.1/SMI-4.1) id AA01204; Wed, 24 Feb 93 18:37:39 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Wed, 24 Feb 1993 18:37:39 -0500 (EST) Message-Id: Date: Wed, 24 Feb 1993 18:37:39 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: I'm pretty sure this is a bug 6.1 appears to execute cmdspecials when -v is specified. ======================================================================8--< From aad@lovecraft Mon Mar 1 06:49:23 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05811; Mon, 1 Mar 93 06:49:23 PST Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #11) id m0nTBMY-0019NBC; Mon, 1 Mar 93 09:20 EST Received: by lovecraft (4.1/SMI-4.1) id AA00310; Fri, 26 Feb 93 14:33:54 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Fri, 26 Feb 1993 14:33:54 -0500 (EST) Message-Id: Date: Fri, 26 Feb 1993 14:33:54 -0500 (EST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: rdist just corrupted my /usr 6.1 beta, Sun 4c's, SunOS 4.1.1, 4.1.3. /local/scr/bin/tcsh is singly linked; /local/scr/bin/{ksh,rksh} are links to the same file. /local/scr/bin/tcsh gets disted to /local/scr/bin/tcsh. I also have had local: ( /local/scr/bin/{tc,k}sh ) -> ( ${ALLSUN4} ) install -oyounger,chknfs,chkreadonly /bin; /bin on the destination machines is a symlink to /usr/bin. One annoyance is that chknfs and chkreadonly appear to check "/bin" on the remote machine, which lives in /, instead of following the link to find the real directory in /usr, which can be NFS-mounted read-only. I think the real thing to do would be to check the full pathname on the remote host. But on to the corruption: I changed the above package to local: ( /local/scr/bin/{tc,k,rk}sh ) -> ( ${ALLSUN4} ) install -oyounger,chknfs,chkreadonly /bin; and rdist decided to make /bin/rksh, and thus /usr/bin/rksh, a HARD LINK TO THE /USR/BIN DIRECTORY! This confused the hell out of getcwd, requiring /usr to be fscked. ======================================================================8--< From mcooper@ucs.usc.edu Tue Mar 2 14:52:54 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11743; Tue, 2 Mar 93 14:52:54 PST Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA18303; Tue, 2 Mar 93 14:52:50 PST Sender: "Michael A. Cooper" Date: Tue, 2 Mar 93 14:52:48 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "Anthony A. Datri" Cc: rdist-dev@usc.edu Subject: Re: rdist just corrupted my /usr In-Reply-To: Your message of Fri, 26 Feb 1993 14:33:54 -0500 (EST) Message-Id: Content-Length: 251 Don Beusee sent me a fix to his hardlink fix several weeks ago that sounds like might fix this. Unfortunetely it was bundled with a number of other patches, all of which will be in the 6.1beta.1 which I will get out as soon as I get a chance. mike From dpk@fid.morgan.com Tue Mar 2 15:35:57 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13503; Tue, 2 Mar 93 15:35:57 PST Received: from Morgan.COM ([138.20.2.27]) by gateway.morgan.com with SMTP id <41390>; Tue, 2 Mar 1993 18:35:44 -0500 Received: from foreign.Morgan.COM by Morgan.COM id AA12589; Tue, 2 Mar 93 18:35:36 EST Date: Tue, 2 Mar 1993 18:35:36 -0500 From: dpk@fid.Morgan.COM (Doug Kingston) Message-Id: <9303021835.ZM25261@foreign.fid.morgan.com> X-Mailer: Z-Mail (2.1b.1326 26jan93 OpenLook) To: rdist-dev@usc.edu Subject: replacing dir with symlink Cc: crp@rs2 I would like to propose that the following change be made to the code that replaces directories with symlinks: Currently if it goes to replace a directory with a symlink, it first recursively removes the directory (possibly taking some large number of seconds) and then installs the symlink. This can create large periods of time when a directory of stuff can be "partially" present. Instead, I suggest the following strategy: create the symlink using an rdist tmp file name (e.g. rdist123456) rename dirname rdist67890 rename rdist123456 dirname then recursively remove the old directory tree This will make the "inconsistency only last milliseconds instead of perhaps minutes. -Doug- & CRP Doug Kingston Cecilia Panicali From mcooper@ucs.usc.edu Tue Mar 2 16:21:32 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15016; Tue, 2 Mar 93 16:21:32 PST Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA19179; Tue, 2 Mar 93 16:21:28 PST Sender: "Michael A. Cooper" Date: Tue, 2 Mar 93 16:21:26 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.Morgan.COM (Doug Kingston) Cc: rdist-dev@usc.edu, crp@rs2.usc.edu Subject: Re: replacing dir with symlink In-Reply-To: Your message of Tue, 2 Mar 1993 18:35:36 -0500 Message-Id: Content-Length: 26 Sounds reasonable. mike From tito@di.unipi.it Thu Mar 4 01:34:06 1993 Return-Path: Received: from apollo.di.unipi.it by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24154; Thu, 4 Mar 93 01:34:06 PST Message-Id: <9303040934.AA24154@usc.edu> Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA15730; Thu, 4 Mar 93 10:33:07 +0100 Date: Thu, 4 Mar 93 10:33:07 +0100 From: Tito Flagella Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA20339; Thu, 4 Mar 93 10:32:57 +0100 To: dbeusee@us.oracle.com Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Fri, 19 Feb 93 01:29:51 PST <9302190929.AA01938@dbeusee.us.oracle.com> Subject: more rdist patches (another hardlink bug fixed) 4. Fixed bug with hardlink and $REMOTEFILE set wrong when destdir=true. e.g. (a b) -> /tmp 6.1beta seems still buggy reguards to that. I have tried to apply your patch to the 6.1beta getting compilation errors. Anybody can tell me what is the shortest path to get hardlink with destdir=true working with rdist. By, tito. ------------------------------------------------------------------- Tito Flagella Information Technology Consultant Universita' di Pisa --------------------------------- Dipartimento Informatica email: tito@di.unipi.it Corso Italia 40 fax : +39 (50) 510226 I-56125 Pisa tel : +39 (50) 510263 ------------------------------------------------------------------- From dbeusee@us.oracle.com Thu Mar 4 07:47:35 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05392; Thu, 4 Mar 93 07:47:35 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA14428; Thu, 4 Mar 93 07:47:16 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10737; Thu, 4 Mar 93 07:40:48 PST Message-Id: <9303041540.AA10737@dbeusee.us.oracle.com> Date: Thu, 4 Mar 93 07:40:48 PST From: Don Beusee To: tito@di.unipi.it Subject: Re: more rdist patches (another hardlink bug fixed) 4. Fixed bug with hardlink and $REMOTEFILE set wrong when destdir=true. e.g. (a b) -> /tmp Cc: mcooper@usc.edu, rdist-dev@usc.edu You need to apply my previous patches - did you do that? They need to be applied in order. From tito@di.unipi.it Thu Mar 4 01:27:38 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09379; Thu, 4 Mar 93 01:27:37 PST Received: from apollo.di.unipi.it by gatekeeper.oracle.com (5.59.11/37.7) id AA05088; Thu, 4 Mar 93 01:33:59 PST Message-Id: <9303040933.AA05088@gatekeeper.oracle.com> Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA15730; Thu, 4 Mar 93 10:33:07 +0100 Date: Thu, 4 Mar 93 10:33:07 +0100 From: Tito Flagella Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA20339; Thu, 4 Mar 93 10:32:57 +0100 To: dbeusee@us Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Fri, 19 Feb 93 01:29:51 PST <9302190929.AA01938@dbeusee.us.oracle.com> Subject: more rdist patches (another hardlink bug fixed) 4. Fixed bug with hardlink and $REMOTEFILE set wrong when destdir=true. e.g. (a b) -> /tmp Status: R 6.1beta seems still buggy reguards to that. I have tried to apply your patch to the 6.1beta getting compilation errors. Anybody can tell me what is the shortest path to get hardlink with destdir=true working with rdist. By, tito. ------------------------------------------------------------------- Tito Flagella Information Technology Consultant Universita' di Pisa --------------------------------- Dipartimento Informatica email: tito@di.unipi.it Corso Italia 40 fax : +39 (50) 510226 I-56125 Pisa tel : +39 (50) 510263 ------------------------------------------------------------------- From rouilj@cs.umb.edu Fri Mar 12 12:47:55 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14744; Fri, 12 Mar 93 12:47:55 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA05228 (5.65c/IDA-1.4.4 for ); Fri, 12 Mar 1993 15:47:32 -0500 Message-Id: <199303122047.AA05228@cs.umb.edu> To: rdist-dev@usc.edu Subject: Fixing -o savetargets where target needs to be installed Date: Fri, 12 Mar 1993 15:47:32 -0500 From: "John P. Rouillard" I usually run rdist with -o savetargets, especially whan I am using it to customize a hosts that has a new revision of the operating system. However, when using savetargets, and the remote file doesn't exist, and error is generated, and the file is not installed. I regard this as a bug, and was planning on fixing it by checking to see if the errno was ENOENT when the rename call failed. If it was ENOENT, I would just continue along quietly. However, on further thinking, I was wondering if it would be better to explicitly stat the file to be replaced to see if it exists. If it doesn't exist, I would send a message and skip the rename all together. Comments? -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From mcooper@acamar.usc.edu Fri Mar 12 16:08:53 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19387; Fri, 12 Mar 93 16:08:53 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA24146; Fri, 12 Mar 93 16:08:31 PST Sender: "Michael A. Cooper" Date: Fri, 12 Mar 93 16:08:31 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "John P. Rouillard" Cc: rdist-dev@usc.edu Subject: Re: Fixing -o savetargets where target needs to be installed In-Reply-To: Your message of Fri, 12 Mar 1993 15:47:32 -0500 Message-Id: Content-Length: 189 Yeah, that sounds like a bug, but I don't think you should worry about the save file already existing. The save suffix you use should always be something that is safe to overwrite. mike From neal@ctd.comsat.com Mon Mar 15 10:39:22 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25125; Mon, 15 Mar 93 10:39:22 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nYK4A-0003TdC; Mon, 15 Mar 93 13:39 EST Message-Id: Date: Mon, 15 Mar 93 13:39 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: can I do this with 'special'? Does special use /bin/sh? Can I do something like this: special /etc/syslogd.conf "kill `cat /etc/syslogd.pid`; /etc/syslogd" (note the backquotes) Thanks. From mcooper@acamar.usc.edu Mon Mar 15 13:20:42 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29166; Mon, 15 Mar 93 13:20:42 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA00185; Mon, 15 Mar 93 13:20:37 PST Sender: "Michael A. Cooper" Date: Mon, 15 Mar 93 13:20:36 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist@usc.edu Subject: Re: can I do this with 'special'? In-Reply-To: Your message of Mon, 15 Mar 93 13:39 EST Message-Id: Content-Length: 57 Yes, /bin/sh is used for all *special() commands. mike From mcooper@acamar.usc.edu Tue Mar 16 13:53:46 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02271; Tue, 16 Mar 93 13:53:46 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA03463; Tue, 16 Mar 93 13:53:42 PST Sender: "Michael A. Cooper" Date: Tue, 16 Mar 93 13:53:41 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Cc: arlet@einstein.et.tudelft.nl Subject: Important rdist security patch Message-Id: Content-Length: 1026 Much as I tried to avoid this, I blew it. There's a big security hole in rdist 6.0.x and 6.1beta.0 that allows any user to overwrite any file. A patch can be found below and is out for ftp on usc.edu as /pub/rdist/Security.patch. Thanks go to Arlet Ottens for pointing out the problem. mike The patch below fixes a very bug security hole that allows any user to overwrite any file on your system using rdist. This patch should work with rdist 6.0.0 and 6.1beta.0. mike *** rdist.c.ORIG Tue Mar 16 13:38:43 1993 --- rdist.c Tue Mar 16 13:38:44 1993 *************** *** 111,116 **** --- 111,119 ---- exit(1); } + if (dosetreuid(0, userid) != 0) + exit(1); + while ((c = getopt(argc, argv, optchars)) != -1) switch (c) { case 'l': *************** *** 217,225 **** if (nflag && IS_ON(options, DO_VERIFY)) fatal("The -n flag and \"verify\" mode may not both be used."); - - if (dosetreuid(0, userid) != 0) - exit(1); /* * Don't fork children for nflag --- 220,225 ---- From rick@cb18.sbi.com Sun Mar 21 21:45:20 1993 Return-Path: Received: from uu5.psi.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18397; Sun, 21 Mar 93 21:45:20 PST Received: from sbi.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA29336 for rdist-dev@usc.edu; Mon, 22 Mar 93 00:45:27 -0500 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA03264; Mon, 22 Mar 93 00:45:09 EST Received: from cb18.tokyo-pro1 (cb18.sbi.com) by sbi.sbi.com (4.1/SMI-4.1) id AA22615; Mon, 22 Mar 93 00:45:06 EST Received: by cb18.tokyo-pro1 (4.1/SMI-4.1) id AA22900; Mon, 22 Mar 93 14:44:46 JST Date: Mon, 22 Mar 93 14:44:46 JST From: rick@cb18.sbi.com (Rick Flynn) Message-Id: <9303220544.AA22900@cb18.tokyo-pro1> To: rdist-dev@usc.edu Subject: A few questions Having recently exchanged a wee bit of email with Mike Cooper, he suggested that I raise my issues regarding the USC Rdist here: - Compression: For those of us who move 100s of Megabytes of data across WAN's daily, an option to do the rdist transfer compressed would be, as they say, simply sporty - international bandwidth is a bit on the pricy side and moving around 300Meg files is a bit slow. Has this ever been considered or the USC Rdist? - Checksum tests: For those of us with the WAN again, a checksum test to verify if a file had changed would be infinitely more pleasant than the current (I think) method of transfering a complete copy of the file and then doing a byte by byte comparison. Has there been any progess on this in the USC Rdist? That's it - as you can see, I am quite plainly interested in the Rdist performance with large amounts of data over WANs. Burning some cpu cycles on each end to compress/decompress (or checksum as the case may be) would be preferable to soaking the WAN, especially if it is semi-tunable like the GNU gzip --fast/--best. thankx in advance rick From dpk@fid.morgan.com Mon Mar 22 11:48:40 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19086; Mon, 22 Mar 93 11:48:40 PST Received: from Morgan.COM ([138.20.2.27]) by gateway.morgan.com with SMTP id <41385>; Mon, 22 Mar 1993 14:48:20 -0500 Received: from admiralty by Morgan.COM id AA15600; Mon, 22 Mar 93 14:48:14 EST Received: by admiralty (AIX 3.2/UCB 5.64/4.03.MS.1) id AA12350; Mon, 22 Mar 1993 14:48:12 -0500 From: dpk@fid.Morgan.COM (Doug Kingston) Message-Id: <9303221448.ZM15932@admiralty.fid.morgan.com> Date: Mon, 22 Mar 1993 14:48:08 -0500 In-Reply-To: rick@cb18.sbi.com (Rick Flynn) "A few questions" (Mar 22, 0:44) References: <9303220544.AA22900@cb18.tokyo-pro1> X-Mailer: Z-Mail (2.1.3 26jan93) To: rick@cb18.sbi.com (Rick Flynn), rdist-dev@usc.edu Subject: Re: A few questions As a heavy user of national and international WAN bandwidth, I would also appreciate these changes if they were part of "standard" rdist. On Mar 22, 0:44, Rick Flynn wrote: } Subject: A few questions } } Having recently exchanged a wee bit of email with Mike Cooper, he suggested } that I raise my issues regarding the USC Rdist here: } } - Compression: } ... } } } - Checksum tests: } ... } } That's it - as you can see, I am quite plainly interested in the Rdist } performance with large amounts of data over WANs. Burning some cpu } cycles on each end to compress/decompress (or checksum as the case may } be) would be preferable to soaking the WAN, especially if it is semi-tunable } like the GNU gzip --fast/--best. } } thankx in advance } } rick }-- End of excerpt from Rick Flynn From dbeusee@us.oracle.com Tue Mar 23 15:39:23 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13552; Tue, 23 Mar 93 15:39:23 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA05080; Tue, 23 Mar 93 15:39:20 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04421; Tue, 23 Mar 93 15:33:00 PST Message-Id: <9303232333.AA04421@dbeusee.us.oracle.com> Date: Tue, 23 Mar 93 15:33:00 PST From: Don Beusee To: mcooper@usc.edu Subject: Re: directory assumption Cc: rdist-dev@usc.edu Well, this patch will not change the behaviour when the source (on left side of ->) is a symlink. But if it is a directory, rdist is enhanced to assume the target will be a directory. DO you have any problem with that? Comments? From mcooper@acamar.usc.edu Sat Mar 20 17:04:44 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28593; Sat, 20 Mar 93 17:04:41 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA12750; Sat, 20 Mar 93 17:10:59 PST Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13966; Sat, 20 Mar 93 16:23:15 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA21420; Sat, 20 Mar 93 16:23:11 PST Sender: "Michael A. Cooper" Date: Sat, 20 Mar 93 16:23:10 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dbeusee@us Subject: directory assumption Message-Id: Content-Length: 1051 Status: R Don, I'm going through all the diffs you sent me and ran across the following for docmd.c: + /* + * destination is a directory if one of the following is true: + * a) more than one name specified on left side of -> directive + * b) basename of destination in "install" directive is "." + * (e.g. install /tmp/.;) + * c) name on left side of -> directive is a directory on local system. + */ ddir = files->n_next != NULL; /* destination is a directory */ + if (!ddir && sbcmds->sc_name && *sbcmds->sc_name) + ddir = !strcmp(basename(sbcmds->sc_name),"."); + if (!ddir) { + struct stat s; + if (lstat(files->n_name, &s) == 0) + ddir = S_ISDIR(s.st_mode); + } While I see no problem with a) and b), I think c) may cause problems for people who may be assuming the current behavior of link+directory handling. You might want to send a message to rdist-dev and see what the consense is on this one. mike From dbeusee@us.oracle.com Tue Mar 23 16:07:18 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14361; Tue, 23 Mar 93 16:07:18 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA06454; Tue, 23 Mar 93 16:07:08 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04544; Tue, 23 Mar 93 16:00:47 PST Message-Id: <9303240000.AA04544@dbeusee.us.oracle.com> Date: Tue, 23 Mar 93 16:00:47 PST From: Don Beusee To: rdist-dev@usc.edu, rick@cb18.sbi.com Subject: Re: A few questions I think these should be "options" myself! From rick@cb18.sbi.com Sun Mar 21 22:00:33 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00219; Sun, 21 Mar 93 22:00:32 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA07309; Sun, 21 Mar 93 22:06:50 PST Received: from uu5.psi.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18397; Sun, 21 Mar 93 21:45:20 PST Received: from sbi.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA29336 for rdist-dev@usc.edu; Mon, 22 Mar 93 00:45:27 -0500 Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA03264; Mon, 22 Mar 93 00:45:09 EST Received: from cb18.tokyo-pro1 (cb18.sbi.com) by sbi.sbi.com (4.1/SMI-4.1) id AA22615; Mon, 22 Mar 93 00:45:06 EST Received: by cb18.tokyo-pro1 (4.1/SMI-4.1) id AA22900; Mon, 22 Mar 93 14:44:46 JST Date: Mon, 22 Mar 93 14:44:46 JST From: rick@cb18.sbi.com (Rick Flynn) Message-Id: <9303220544.AA22900@cb18.tokyo-pro1> To: rdist-dev@usc.edu Subject: A few questions Status: R Having recently exchanged a wee bit of email with Mike Cooper, he suggested that I raise my issues regarding the USC Rdist here: - Compression: For those of us who move 100s of Megabytes of data across WAN's daily, an option to do the rdist transfer compressed would be, as they say, simply sporty - international bandwidth is a bit on the pricy side and moving around 300Meg files is a bit slow. Has this ever been considered or the USC Rdist? - Checksum tests: For those of us with the WAN again, a checksum test to verify if a file had changed would be infinitely more pleasant than the current (I think) method of transfering a complete copy of the file and then doing a byte by byte comparison. Has there been any progess on this in the USC Rdist? That's it - as you can see, I am quite plainly interested in the Rdist performance with large amounts of data over WANs. Burning some cpu cycles on each end to compress/decompress (or checksum as the case may be) would be preferable to soaking the WAN, especially if it is semi-tunable like the GNU gzip --fast/--best. thankx in advance rick From tito@di.unipi.it Wed Mar 24 05:50:39 1993 Return-Path: Received: from apollo.di.unipi.it by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28674; Wed, 24 Mar 93 05:50:39 PST Message-Id: <9303241350.AA28674@usc.edu> Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA10284; Wed, 24 Mar 93 14:49:03 +0100 Date: Wed, 24 Mar 93 14:49:03 +0100 From: Tito Flagella Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA06472; Wed, 24 Mar 93 14:48:51 +0100 To: dbeusee@us.oracle.com Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Tue, 23 Mar 93 15:33:00 PST <9303232333.AA04421@dbeusee.us.oracle.com> Subject: directory assumption My opoinion is that this is a violation of the principle that rdist mantain "identical" copies of files over multiple hosts, and it should not be accepted. tito. From dbeusee@us.oracle.com Wed Mar 24 10:57:09 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06487; Wed, 24 Mar 93 10:57:09 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11104; Wed, 24 Mar 93 10:56:53 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07722; Wed, 24 Mar 93 10:50:28 PST Message-Id: <9303241850.AA07722@dbeusee.us.oracle.com> Date: Wed, 24 Mar 93 10:50:28 PST From: Don Beusee To: tito@di.unipi.it Subject: Re: directory assumption Cc: mcooper@usc.edu, rdist-dev@usc.edu I don't understand - exactly what violates that? Actually my changes IMPROVE it! From tito@di.unipi.it Wed Mar 24 05:44:06 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07393; Wed, 24 Mar 93 05:44:05 PST Received: from apollo.di.unipi.it by gatekeeper.oracle.com (5.59.11/37.7) id AA26632; Wed, 24 Mar 93 05:50:18 PST Message-Id: <9303241350.AA26632@gatekeeper.oracle.com> Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA10284; Wed, 24 Mar 93 14:49:03 +0100 Date: Wed, 24 Mar 93 14:49:03 +0100 From: Tito Flagella Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA06472; Wed, 24 Mar 93 14:48:51 +0100 To: dbeusee@us Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Tue, 23 Mar 93 15:33:00 PST <9303232333.AA04421@dbeusee.us.oracle.com> Subject: directory assumption Status: R My opoinion is that this is a violation of the principle that rdist mantain "identical" copies of files over multiple hosts, and it should not be accepted. tito. From tito@di.unipi.it Wed Mar 24 16:04:09 1993 Return-Path: Received: from apollo.di.unipi.it by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14374; Wed, 24 Mar 93 16:04:09 PST Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA17195; Thu, 25 Mar 93 01:03:23 +0100 Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA10529; Thu, 25 Mar 93 01:03:16 +0100 Date: Thu, 25 Mar 93 01:03:16 +0100 From: tito@di.unipi.it Message-Id: <9303250003.AA10529@olimpo.di.unipi.it> To: dbeusee@us.oracle.com Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Wed, 24 Mar 93 10:50:28 PST <9303241850.AA07722@dbeusee.us.oracle.com> Subject: directory assumption >From dbeusee@us.oracle.com Wed Mar 24 19:56:21 1993 Date: Wed, 24 Mar 93 10:50:28 PST From: Don Beusee I don't understand - exactly what violates that? Actually my changes IMPROVE it! When I have a link on a target machine and a directory on the source machine, rdist must ensure the link will be made a directory. In your assumption this is no longer possible. So in this case rdist is unable to mantain identical copies of files, requiring they already conform each other. tito. From dbeusee@us.oracle.com Wed Mar 24 16:58:57 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15790; Wed, 24 Mar 93 16:58:57 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA28947; Wed, 24 Mar 93 16:58:52 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08487; Wed, 24 Mar 93 16:52:32 PST Message-Id: <9303250052.AA08487@dbeusee.us.oracle.com> Date: Wed, 24 Mar 93 16:52:32 PST From: Don Beusee To: tito@di.unipi.it Subject: Re: directory assumption Cc: mcooper@usc.edu, rdist-dev@usc.edu That is not true. With my change, rdist will see that the source is a dir, and assume the target is also a dir. No problem here. From tito@di.unipi.it Wed Mar 24 15:59:48 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08355; Wed, 24 Mar 93 15:59:47 PST Received: from apollo.di.unipi.it by gatekeeper.oracle.com (5.59.11/37.7) id AA26836; Wed, 24 Mar 93 16:05:58 PST Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA17195; Thu, 25 Mar 93 01:03:23 +0100 Received: by olimpo.di.unipi.it (4.1/SMI-4.1) id AA10529; Thu, 25 Mar 93 01:03:16 +0100 Date: Thu, 25 Mar 93 01:03:16 +0100 From: tito@di.unipi.it Message-Id: <9303250003.AA10529@olimpo.di.unipi.it> To: dbeusee@us Cc: mcooper@usc.edu, rdist-dev@usc.edu In-Reply-To: Don Beusee's message of Wed, 24 Mar 93 10:50:28 PST <9303241850.AA07722@dbeusee.us.oracle.com> Subject: directory assumption Status: R >From dbeusee@us.oracle.com Wed Mar 24 19:56:21 1993 Date: Wed, 24 Mar 93 10:50:28 PST From: Don Beusee I don't understand - exactly what violates that? Actually my changes IMPROVE it! When I have a link on a target machine and a directory on the source machine, rdist must ensure the link will be made a directory. In your assumption this is no longer possible. So in this case rdist is unable to mantain identical copies of files, requiring they already conform each other. tito. From dbeusee@us.oracle.com Thu Mar 25 03:19:29 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27683; Thu, 25 Mar 93 03:19:29 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA14001; Thu, 25 Mar 93 03:19:27 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09983; Thu, 25 Mar 93 03:13:06 PST Message-Id: <9303251113.AA09983@dbeusee.us.oracle.com> Date: Thu, 25 Mar 93 03:13:06 PST From: Don Beusee To: rdist-dev@usc.edu Subject: rdist patch buggy One of my patches is causing rdist to behave incorrectly. ie.. dir -> host install newdir/.; Puts dir into newdir instead of installing dir as newdir. I will look into this later... From mcooper@acamar.usc.edu Sat Mar 27 16:03:32 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10851; Sat, 27 Mar 93 16:03:32 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA20658; Sat, 27 Mar 93 16:03:29 PST Sender: "Michael A. Cooper" Date: Sat, 27 Mar 93 16:03:28 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.1beta.1 now available Message-Id: Content-Length: 3499 Rdist 6.1beta.1 is now available for anonymous ftp on usc.edu as "/pub/rdist/rdist-6.1beta.1.tar.z". Please note that most of rdist files out for ftp are now compressed using GNU gzip. If you don't have gzip, you can snag a copy from usc.edu from /pub/gzip or direct from GNU on prep.ai.mit.edu. A list of changes appears below. One item that didn't make it in this release is being able to get rdist to display the filename as it is installed on the remote host. I wanted to include this feature with the ability to specify a printf like message format string. However, it's kinda messy to do so due to the global variable clutter left over from the original code. I'm seriously considering doing that full re-write I've put off for so long, but I just don't have time. Sigh. mike Sat Mar 27 12:05:56 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.1beta.1 * Add support for SGI IRIX 4.x and MIPSos 4.x. (Eric Murray) * Set $IFS when running popen() to avoid possible security whole. * Don't print error when doing a savetarget for a new file. * Add "nochkmode" option. * Fix hardlink bug with relative path names. * Upper case REMOTE ERROR and LOCAL ERROR. * Handle ~ in hardlink paths. (Hans Ranke) * Disable SETARGS for Ultrix. It breaks "notify". * Fix problem with server hanging if mkdir fails. (Hans Ranke) * Add support for DEC OSF/1. (Hans Ranke) Sat Mar 20 12:56:17 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Destination is a directory if: a) more than one name specified on left side of -> directive b) basename of destination in "install" directive is "." (Don Beusee) * Dont print 'updating host...' for MT_DEBUG. (Don Beusee) * Add support for setting $REMFILE (remote file name) for "special". (Don Beusee) * Fix problem with getting out of sync when "File changed size". * Add test to see if a child proc is still running to avoid looping. * Avoid bug in SunC which would cause dosetreuid() to never display error on failure. Tue Mar 16 15:59:24 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix security hole that allowed any user to write any file. Tue Mar 9 18:14:22 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem with cmdspecial always being run. Tue Feb 23 16:00:33 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix getmountent() code for SVR4 to use correct mntent member. Sat Feb 20 10:48:10 1993 Michael A. Cooper (mcooper@crucis.usc.edu) * Remove extraneous LIB_* from config/mf.*. * Fix filesystem freespace checking for 512block filesys. (John P. Rouillard) * Add initial POSIX support. * Add support for '&' set operator. (William L. Sebok) * Add support for Multiflow tracebsd. (William L. Sebok) * Add support for DC/OSx, Dynix, Dynix/Ptx. (Don Beusee) * Remove unneeded gettimeofday() call in client. * Only use fchown() if HAVE_FCHOWN is defined. * Only use fchmod() if HAVE_FCHMOD is defined. * Use new POINTER type for *alloc() declares. * Typecast return of strlen(). (Don Beusee) * Define set file time types (SETFTIME_*). * In os-type, use uname if available. * Consoladate the Elf and Coff isexec() code. * Move all missing/*.c files to src/*.c in order to make it possible to specify no missing files. Fri Feb 19 19:51:07 1993 Michael A. Cooper (mcooper@crucis.usc.edu) * Redo makefiles again to use external "runmake" script to build and run make. * Set BIN_DIR to /usr/bin for sunos5. From dbeusee@us.oracle.com Sat Mar 27 16:11:51 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11020; Sat, 27 Mar 93 16:11:51 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA24046; Sat, 27 Mar 93 16:11:50 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA17943; Sat, 27 Mar 93 16:05:31 PST Message-Id: <9303280005.AA17943@dbeusee.us.oracle.com> Date: Sat, 27 Mar 93 16:05:31 PST From: Don Beusee To: rdist-dev@usc.edu Subject: patch to fix bug with my Feb22 patch I sent a note yesterday or the day before promising to deliver a patch for a problem I found with rdisting a single directory. Here it is... I sent a patch out on Feb 22 with subject: another rdist patch (hardlink, destdir, debugmsg) The first item in that patch caused the problem: > 1) destdir flag was zero when using the following syntax: > dir -> hosta > install /tmp; > with this patch, if only one file specified before -> and that file is a > directory, then the target is also assumed to be a directory (set destdir=1). What happened as a result of that patch was that dir was pushed as /tmp/dir instead of dir's contents being in /tmp as expected. This patch uses 2 seperate destdir flags to fix this bug. One for remfilename() and one for install(). Both destdir and ddir are passed to install(). remfilename() is used to set the FILE variables and also used by the hardlink code to determine the correct remote filename. I put the following comment lines in docmd.c to document the need for the 2 destdir flags: * * We need 2 destdir flags (destdir and ddir) because single directory * source is handled differently. In this case, ddir is 0 (which * tells install() not to send DIRTARGET directive to remote rdistd) * and destdir is 1 (which tells remfilename() how to build the FILE * variables correctly). In every other case, destdir and ddir will * have the same value. */ The above fixes are for client.c and docmd.c. There is another fix in docmd.c (included in this patch) that turns "notify..." messages into non-debug messages, since the noquiet option control whether this message is given or not. server.c needs a patch so that the mkdir notices are debug messages instead. as non-debug messages, one would think mkdir was failing. This fix is also included in this patch. The following patch must be applied after all of my previous patches are applied (in the order I sent them and including the bad Feb 22 patch). Here is the shar file containing diffs for client.c, docmd.c, and server.c. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.docmd.c # patch.server.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.6 1993/02/22 09:23:59 X--- src/client.c 1993/03/27 21:42:33 X*************** X*** 1046,1054 **** X * Return > 0 if something was updated. X */ X extern int X! install(src, dest, destdir, opts) X char *src, *dest; X! int destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X--- 1046,1054 ---- X * Return > 0 if something was updated. X */ X extern int X! install(src, dest, ddir, destdir, opts) X char *src, *dest; X! int ddir, destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X*************** X*** 1096,1101 **** X--- 1096,1102 ---- X if (IS_ON(opts, DO_WHOLE)) { X while (*rname == '/') X rname++; X+ ddir = 1; X destdir = 1; X } else { X rname = strrchr(target, '/'); X*************** X*** 1109,1121 **** X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d\n", X! target, source, rname, dest, destdir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (destdir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); X--- 1110,1122 ---- X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d, ddir=%d\n", X! target, source, rname, dest, destdir, ddir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (ddir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.docmd.c && X*** 1.4 1993/03/27 21:12:44 X--- src/docmd.c 1993/03/27 22:18:29 X*************** X*** 103,109 **** X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO|MT_DEBUG, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X--- 103,109 ---- X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X*************** X*** 381,387 **** X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X--- 381,387 ---- X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, destdir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X*************** X*** 402,416 **** X * b) basename of destination in "install" directive is "." X * (e.g. install /tmp/.;) X * c) name on left side of -> directive is a directory on local system. X */ X ddir = files->n_next != NULL; /* destination is a directory */ X- if (!ddir && sbcmds->sc_name && *sbcmds->sc_name) X- ddir = !strcmp(basename(sbcmds->sc_name),"."); X if (!ddir) { X struct stat s; X if (lstat(files->n_name, &s) == 0) X! ddir = S_ISDIR(s.st_mode); X! } X if (nflag) X (void) printf("updating host %s\n", rhost); X else { X--- 402,427 ---- X * b) basename of destination in "install" directive is "." X * (e.g. install /tmp/.;) X * c) name on left side of -> directive is a directory on local system. X+ * X+ * We need 2 destdir flags (destdir and ddir) because single directory X+ * source is handled differently. In this case, ddir is 0 (which X+ * tells install() not to send DIRTARGET directive to remote rdistd) X+ * and destdir is 1 (which tells remfilename() how to build the FILE X+ * variables correctly). In every other case, destdir and ddir will X+ * have the same value. X */ X ddir = files->n_next != NULL; /* destination is a directory */ X if (!ddir) { X struct stat s; X+ int isadir; X if (lstat(files->n_name, &s) == 0) X! isadir = S_ISDIR(s.st_mode); X! if (!isadir && sbcmds->sc_name && *sbcmds->sc_name) X! ddir = !strcmp(basename(sbcmds->sc_name),"."); X! destdir = isadir | ddir; X! } else X! destdir = ddir; X! X if (nflag) X (void) printf("updating host %s\n", rhost); X else { X*************** X*** 446,459 **** X if (sc->sc_type != INSTALL) X continue; X n++; X! if (install(f->n_name, sc->sc_name, X! sc->sc_name == NULL ? 0 : ddir, X sc->sc_options) > 0) X ++didupdate; X opts = sc->sc_options; X } X if (n == 0) X! if (install(f->n_name, (char *) NULL, 0, options) > 0) X ++didupdate; X } X X--- 457,470 ---- X if (sc->sc_type != INSTALL) X continue; X n++; X! if (install(f->n_name, sc->sc_name, ddir, destdir, X sc->sc_options) > 0) X ++didupdate; X opts = sc->sc_options; X } X if (n == 0) X! if (install(f->n_name, NULL, ddir, destdir, options) X! > 0) X ++didupdate; X } X SHAR_EOF chmod 0644 patch.docmd.c || echo "restore of patch.docmd.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.server.c && X*** 1.3 1993/02/19 22:39:10 X--- src/server.c 1993/03/27 22:20:45 X*************** X*** 600,606 **** X if (lstat(name, &stb) < 0) { X if (errno == ENOENT && chkparent(name, opts) >= 0) { X if (mkdir(name, 0777 & ~oumask) == 0) { X! message(MT_NOTICE, "%s: mkdir", name); X r = 0; X } else X debugmsg(DM_MISC, X--- 600,606 ---- X if (lstat(name, &stb) < 0) { X if (errno == ENOENT && chkparent(name, opts) >= 0) { X if (mkdir(name, 0777 & ~oumask) == 0) { X! debugmsg(DM_MISC, "%s: mkdir", name); X r = 0; X } else X debugmsg(DM_MISC, X*************** X*** 953,959 **** X if (mkdir(target, mode) == 0 || X chkparent(target, opts) == 0 && X mkdir(target, mode) == 0) { X! message(MT_NOTICE, "%s: mkdir", target); X if (fchog(-1, target, owner, group, mode) == 0) X ack(); X } X--- 953,959 ---- X if (mkdir(target, mode) == 0 || X chkparent(target, opts) == 0 && X mkdir(target, mode) == 0) { X! debugmsg(DM_MISC, "%s: mkdir", target); X if (fchog(-1, target, owner, group, mode) == 0) X ack(); X } SHAR_EOF chmod 0644 patch.server.c || echo "restore of patch.server.c fails" exit 0 From dbeusee@us.oracle.com Sat Mar 27 23:14:31 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16883; Sat, 27 Mar 93 23:14:31 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA28984; Sat, 27 Mar 93 23:14:29 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA18569; Sat, 27 Mar 93 23:08:11 PST Message-Id: <9303280708.AA18569@dbeusee.us.oracle.com> Date: Sat, 27 Mar 93 23:08:11 PST From: Don Beusee To: rdist-dev@usc.edu Subject: last rdist patch for destdir bug I sent the patch out before I completed testing and I found one bug that causes a core dump. Here is the diff (apply this after applying the patch I sent out earlier today): *** 1.5 1993/03/27 23:21:57 --- src/docmd.c 1993/03/28 06:40:06 *************** *** 422,427 **** --- 422,432 ---- } else destdir = ddir; + if (!sbcmds->sc_name || !*sbcmds->sc_name) { + destdir = 0; + ddir = 0; + } + if (nflag) (void) printf("updating host %s\n", rhost); else { From rouilj@cs.umb.edu Sun Mar 28 14:10:59 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28244; Sun, 28 Mar 93 14:10:59 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA28935 (5.65c/IDA-1.4.4 for ); Sun, 28 Mar 1993 17:10:57 -0500 Message-Id: <199303282210.AA28935@cs.umb.edu> To: rdist-dev@usc.edu Subject: rdist 6.1beta 1 bugs riscos 4.x, irix 4.0.5, sinix, USL svr4 Date: Sun, 28 Mar 1993 17:10:56 -0500 From: "John P. Rouillard" I just finished my compiles on all of the above platforms: When compiling on mips/riscos or irix: The files os-mipsos4.h (which should be os-riscos.h), and os-irix.h are missing the last 4 definitions in os-TEMPLATE.h. Also, mips can't handle SETARGS being defined (at least 4.5{1,2} can't handle it). Also, neither irix nor riscos (mipsos) is missing: strcasecmp.o regex.o, these objects can be removed from the MISSING objects line. You have to use the -systype bsd43 flag on riscos 4.5x so that include files will be found. This doesn't seem to be the case with riscos 5.0, but I don't have a full compile yet. Also both os files are missing the definitions for POINTER, SETFTIMETYPE, and TEST_SIGNAL which cause compiler failures. (Actually the entire bottom section of os-TEMPLATE.h is missing from these files). Also, in the irix setup there are some misdefinitions that use long in place of the uid_t etc that evoke (gratuitous) compiler warnings. For SVR4 based systems: Also, a definition of hasmntopt is needed for svr4 from usl, and for sinix since they appear to be missing the function. Under svr4 for the makefiles make sure the shell is defined in the runmake script. One make in particular won't use SHELL= for its child processes. Best alternative, use gnu make. That is what I did. For all compiles: The function common.c:setfiletime() cam compile successfully without a definition for SETFTIMETYPE. I think this is wrong. Any time rdist is run, it will update all of the files in the distfile. If somebody wants to do that, they should probably look at rcp or tar. In the top level makefile, the clean target and install targets don't work becuse the "target" variable is never exported to the shell where the inferior make is done. Actually in the clean target, the "target" variable is never defined. As soon as I clean up some odds and end's (probably by monday night) I'll release a set of patches for this code that worked for me. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj@cs.umb.edu Sun Mar 28 14:45:26 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28523; Sun, 28 Mar 93 14:45:26 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA29451 (5.65c/IDA-1.4.4 for ); Sun, 28 Mar 1993 17:45:25 -0500 Message-Id: <199303282245.AA29451@cs.umb.edu> To: rdist-dev@usc.edu Subject: One more point on irix Date: Sun, 28 Mar 1993 17:45:25 -0500 From: "John P. Rouillard" Irix can't handle SETARGS either. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Sun Mar 28 17:54:39 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01034; Sun, 28 Mar 93 17:54:39 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA13870; Sun, 28 Mar 93 17:54:34 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20120; Sun, 28 Mar 93 17:48:17 PST Message-Id: <9303290148.AA20120@dbeusee.us.oracle.com> Date: Sun, 28 Mar 93 17:48:17 PST From: Don Beusee To: rdist-dev@usc.edu, rouilj@ra.cs.umb.edu Subject: Re: One more point on irix My advice is to trash the SETARGS code altogether. It does not work on most platforms and it trashes the environment on some platforms. It is not worth the hastles. Regards, Don. From rouilj@cs.umb.edu Sun Mar 28 14:52:04 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA19901; Sun, 28 Mar 93 14:52:03 PST Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA11049; Sun, 28 Mar 93 14:58:18 PST Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28523; Sun, 28 Mar 93 14:45:26 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA29451 (5.65c/IDA-1.4.4 for ); Sun, 28 Mar 1993 17:45:25 -0500 Message-Id: <199303282245.AA29451@cs.umb.edu> To: rdist-dev@usc.edu Subject: One more point on irix Date: Sun, 28 Mar 1993 17:45:25 -0500 From: "John P. Rouillard" Status: R Irix can't handle SETARGS either. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Mon Mar 29 15:19:24 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24180; Mon, 29 Mar 93 15:19:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA23904; Mon, 29 Mar 93 15:19:22 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21820; Mon, 29 Mar 93 15:13:05 PST Message-Id: <9303292313.AA21820@dbeusee.us.oracle.com> Date: Mon, 29 Mar 93 15:13:05 PST From: Don Beusee To: rdist-dev@usc.edu Subject: on last destdir patch to fix another core dump This should be the last patch. This fixes a core dump when you have a distfile like this: (files) -> (hosts) i.e. when no install directive was used, my destdir patch would core dump. apply this diff patch to docmd.c: *** 1.6 1993/03/29 23:08:46 --- docmd.c 1993/03/29 23:13:25 *************** *** 422,428 **** } else destdir = ddir; ! if (!sbcmds->sc_name || !*sbcmds->sc_name) { destdir = 0; ddir = 0; } --- 422,428 ---- } else destdir = ddir; ! if (!sbcmds || !sbcmds->sc_name || !*sbcmds->sc_name) { destdir = 0; ddir = 0; } From rouilj@cs.umb.edu Thu Apr 1 18:24:20 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04801; Thu, 1 Apr 93 18:24:20 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA23446 (5.65c/IDA-1.4.4 for ); Thu, 1 Apr 1993 21:24:16 -0500 Message-Id: <199304020224.AA23446@cs.umb.edu> To: rdist-dev@usc.edu Subject: Problem with */. processing in 6.1b1 Date: Thu, 01 Apr 1993 21:24:14 -0500 From: "John P. Rouillard" The following works: rc: /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) install -h /etc/rc3.d/. ; However this fails: rc: /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) except /config/rc/sinix/rc3.d/* ; install -h /etc/rc3.d/. ; with the following error: RUNNING: /usr/ucb/rdist.v6 -f /config/Distfile/Distfile -m socks rc socks: updating host socks socks: /config/rc/sinix/init.d/nfs: updating socks: REMOTE ERROR: /etc/init.d/rdista0025S -> /etc/init.d/.: rename failed: Invalid argument socks: LOCAL ERROR: update: unexpected response '' The directory /config/rc/sinix/init.d has only one file in it namely "nfs". My master is 6.1b1 running on mips RISCOS 4.51, and the recipient is 6.1b1 on a Sinix 5.41 C0000. Can anybody verify that a map entry like that above works for them, and what is broken the rdist, or the rdistd? Also, does the last set of patches (since sunday) affect this problem? -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From wls@astro.UMD.EDU Fri Apr 2 10:49:41 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08356; Fri, 2 Apr 93 10:49:41 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA26250; Fri, 2 Apr 1993 13:49:39 -0500 Date: Fri, 2 Apr 1993 13:49:39 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199304021849.AA26250@lynx.astro.umd.edu> To: rouilj@ra.cs.umb.edu Subject: Re: Problem with */. processing in 6.1b1 Cc: rdist-dev@usc.edu > The following works: > > rc: > /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) > install -h /etc/rc3.d/. ; > > > However this fails: > > rc: > /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) > except /config/rc/sinix/rc3.d/* ; > install -h /etc/rc3.d/. ; The does look like a pathological case to me --- with the argument of the except statement equal to all of what is being sent. I'm not surprised it failed although it should be able to handle boundary cases like this gracefully. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From rouilj@cs.umb.edu Fri Apr 2 13:10:43 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14468; Fri, 2 Apr 93 13:10:43 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA10499 (5.65c/IDA-1.4.4 for ); Fri, 2 Apr 1993 16:10:38 -0500 Message-Id: <199304022110.AA10499@cs.umb.edu> To: wls@astro.umd.edu (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: Problem with */. processing in 6.1b1 In-Reply-To: Your message of "Fri, 02 Apr 1993 13:49:39 EST." <199304021849.AA26250@lynx.astro.umd.edu> Date: Fri, 02 Apr 1993 16:10:37 -0500 From: "John P. Rouillard" In message <199304021849.AA26250@lynx.astro.umd.edu>, William L. Sebok writes: > > The following works: > > > > rc: > > /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) > > install -h /etc/rc3.d/. ; > > > > > > However this fails: > > > > rc: > > /config/rc/sinix/rc3.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) > > except /config/rc/sinix/rc3.d/* ; > > install -h /etc/rc3.d/. ; > > The does look like a pathological case to me --- with the argument of the > except statement equal to all of what is being sent. I'm not surprised it > failed although it should be able to handle boundary cases like this > gracefully. Grr, sorry the except line was suppsed to read: except /config/rc/sinix/rc3.d/*~ ; I.E. I don't want to send emacs backup files. It did match the file nfs. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Fri Apr 2 14:46:17 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17986; Fri, 2 Apr 93 14:46:17 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA01320; Fri, 2 Apr 93 14:45:55 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03303; Fri, 2 Apr 93 14:39:38 PST Message-Id: <9304022239.AA03303@dbeusee.us.oracle.com> Date: Fri, 2 Apr 93 14:39:38 PST From: Don Beusee To: rouilj@sni-usa.com Subject: Re: Output from debug for /. problem using exclude Cc: mcooper@usc.edu, rdist-dev@usc.edu THis is fixed with all of my destdir patches. My latest ones are not applied to 6.1.b1. Mike, can you incoporate all of my patches into 6.1.b1? I am still using 6.1.b0. This rename error is happening because a single file is being sent to a directory, as in: file -> host install dir; THis is fixed with my patches. Regards, Don. From rouilj@sni-usa.com Fri Apr 2 14:24:13 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03291; Fri, 2 Apr 93 14:24:12 PST Received: from camus.sni-usa.com by gatekeeper.oracle.com (5.59.11/37.7) id AA29995; Fri, 2 Apr 93 14:30:16 PST Received: by camus.sni-usa.com (5.61/4.7) id AA23651; Fri, 2 Apr 93 17:31:05 -0500 Date: Fri, 2 Apr 93 17:31:05 -0500 From: rouilj@sni-usa.com (John Rouillard) Message-Id: <9304022231.AA23651@camus.sni-usa.com> To: dbeusee@us Subject: Output from debug for /. problem using exclude Status: R I commented out all of the other matching rc targets leaving only: rc: /config/rc/sinix/init.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) except /config/rc/sinix/init.d/*~; install /etc/init.d/. ; I invoked rdist as: rdist -m magnum1 -onumchkgroup -D rc Here is the output from a failed run: camus: addchild() start camus: addchild() created 'magnum1' pid 23598 fd 3 (active=1) camus: spawn() Forked child 23598 for host magnum1 active = 1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 251 bytes] magnum1: doarrow(1005d950, magnum1, 1005cba0) start magnum1: makeconn(magnum1) magnum1: updating host magnum1 magnum1: Created notify temp file '/tmp/rdist023598' magnum1: port = 514 local user = root remote user = root magnum1: Command = 'rdistd -S' camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 229 bytes] magnum1: <<< Cmd = V (\126) Msg = "" magnum1: >>> Cmd = V (\126) Msg = "6" magnum1: response() start magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: >>> Cmd = c (\143) Msg = "Hcamus" magnum1: response() start camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 552 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: install -onumchkgroup /config/rc/sinix/init.d/nfs /etc/init.d/. magnum1: install: target=/config/rc/sinix/init.d/nfs src=/config/rc/sinix/init.d/nfs rname=nfs dest='/etc/init.d/.' destdir=0 magnum1: >>> Cmd = t (\164) Msg = "1000000 /etc/init.d/." magnum1: response() start magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: sendit(nfs, 40000) magnum1: except(/config/rc/sinix/init.d/nfs) magnum1: update(nfs, 40000, 10010c18) magnum1: >>> Cmd = Q (\121) Msg = "nfs" camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 406 bytes] magnum1: <<< Cmd = Y (\131) Msg = "1024 733789213 755 root :3" magnum1: update(nfs,) local mode 744 remote mode 755 magnum1: update(nfs,) size 1024 mtime 733789213 owner 'root' grp ':3' magnum1: update status nfs (/config/rc/sinix/init.d/nfs) is 2 magnum1: /config/rc/sinix/init.d/nfs: updating magnum1: >>> Cmd = R (\122) Msg = "1000000 744 2100 733716464 733789213 root :0 nfs" magnum1: response() start camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 95 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: Send file 'nfs' 2100 bytes camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 98 bytes] magnum1: Send file 'nfs' complete. magnum1: >>> Cmd =  (\005) Msg = "" magnum1: response() start camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 133 bytes] magnum1: <<< Cmd =  (\001) Msg = "magnum1: REMOTE ERROR: /etc/init.d/rdista002cL -> /etc/init.d/.: rename failed: Invalid argument" camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23598, 3) start] camus: [readchild(magnum1, 23598, 3) got 200 bytes] magnum1: REMOTE ERROR: /etc/init.d/rdista002cL -> /etc/init.d/.: rename failed: Invalid argument magnum1: updating of magnum1 finished magnum1: closeconn() called magnum1: >>> Cmd =  (\002) Msg = "" camus: [readchild(magnum1, 23598, 3) write done] camus: readchild(magnum1, 23598, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: reap() called camus: waitproc() nonblocking, active children = 1... camus: waitproc() done (activechildren = 1) camus: reap() pid = 23598 status = 0 activechildren=1 camus: waitproc() nonblocking, active children = 1... camus: waitproc() done (activechildren = 1) camus: reap() pid = -1 status = 0 activechildren=1 camus: reap() done camus: reap() done -1 status = 0 acticamus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: waitup() proc 23598 (magnum1) died unexpectedly! camus: [readchild(magnum1, 23598, 3) start] camus: readchild(magnum1, 23598, 3) done: amt = 0 errno = 3 camus: readchild(magnum1, 23598, 3) at EOF camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: childscan() start camus: [readchild(magnum1, 23598, 3) start] camus: readchild(magnum1, 23598, 3) done: amt = 0 errno = 3 camus: readchild(magnum1, 23598, 3) at EOF camus: removechild(magnum1, 23598, 3) start camus: removechild() end camus: childscan() end A Successful run's output using: rc: /config/rc/sinix/init.d/* -> (${SINIX.D_HOSTS} ${SINIX.L_HOSTS}) install /etc/init.d/. ; is: camus: addchild() start camus: addchild() created 'magnum1' pid 23618 fd 3 (active=1) camus: spawn() Forked child 23618 for host magnum1 active = 1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: prev assigned: magnum1 camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 110 bytes] magnum1: doarrow(1005d970, magnum1, 1005cba0) start magnum1: makeconn(magnum1) magnum1: updating host magnum1 camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 141 bytes] magnum1: Created notify temp file '/tmp/rdist023618' magnum1: port = 514 local user = root remote user = root magnum1: Command = 'rdistd -S' camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 101 bytes] magnum1: <<< Cmd = V (\126) Msg = "" magnum1: >>> Cmd = V (\126) Msg = "6" magnum1: response() start camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 128 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: >>> Cmd = c (\143) Msg = "Hcamus" magnum1: response() start camus: [readchild(magnum1, 23618, 3) write done] camus: [readchild(magnum1, 23618, 3) got 338 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: install -onumchkgroup /config/rc/sinix/init.d/nfs /etc/init.d/. magnum1: install: target=/config/rc/sinix/init.d/nfs src=/config/rc/sinix/init.d rname=nfs dest='/etc/init.d/.' destdir=1 magnum1: >>> Cmd = T (\124) Msg = "1000000 /etc/init.d/." magnum1: response() start camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 616 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: sendit(nfs, 40000) magnum1: except(/config/rc/sinix/init.d/nfs) magnum1: update(nfs, 40000, 10010c18) magnum1: >>> Cmd = Q (\121) Msg = "nfs" magnum1: <<< Cmd = Y (\131) Msg = "2100 733789416 744 root :0" magnum1: update(nfs,) local mode 744 remote mode 744 magnum1: update(nfs,) size 2100 mtime 733789416 owner 'root' grp ':0' magnum1: update status nfs (/config/rc/sinix/init.d/nfs) is 2 magnum1: /config/rc/sinix/init.d/nfs: updating magnum1: >>> Cmd = R (\122) Msg = "1000000 744 2100 733716464 733789461 root :0 nfs" magnum1: response() start camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 193 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: Send file 'nfs' 2100 bytes magnum1: Send file 'nfs' complete. magnum1: >>> Cmd =  (\005) Msg = "" magnum1: response() start camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: [readchild(magnum1, 23618, 3) start] camus: [readchild(magnum1, 23618, 3) got 340 bytes] magnum1: <<< Cmd =  (\005) Msg = "" magnum1: recieved ACK magnum1: remfilename: src=/config/rc/sinix/init.d dest=/etc/init.d/. path=/config/rc/sinix/init.d/nfs rname=nfs destdir=1 magnum1: remfilename: remote filename=/etc/init.d/./nfs magnum1: updating of magnum1 finished magnum1: closeconn() called magnum1: >>> Cmd =  (\002) Msg = "" camus: [readchild(magnum1, 23618, 3) write done] camus: readchild(magnum1, 23618, 3) done: amt = -1 errno = 101 camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: waitup() select on 3 (magnum1) camus: reap() called camus: waitproc() nonblocking, active children = 1... camus: waitproc() done (activechildren = 1) camus: reap() pid = 23618 status = 0 activechildren=1 camus: waitproc() nonblocking, active children = 1... camus: waitproc() done (activechildren = 1) camus: reap() pid = -1 status = 0 activechildren=1 camus: reap() done camus: reap() done -1 status = 0 acticamus: waitup() Call select(), activechildren=1 camus: waitup() select returned 1 activechildren = 1 camus: waitup() proc 23618 (magnum1) died unexpectedly! camus: [readchild(magnum1, 23618, 3) start] camus: readchild(magnum1, 23618, 3) done: amt = 0 errno = 3 camus: readchild(magnum1, 23618, 3) at EOF camus: waitup() end camus: Waiting for 1 children to finish. camus: waitup() start camus: childscan() start camus: [readchild(magnum1, 23618, 3) start] camus: readchild(magnum1, 23618, 3) done: amt = 0 errno = 3 camus: readchild(magnum1, 23618, 3) at EOF camus: removechild(magnum1, 23618, 3) start camus: removechild() end camus: childscan() end All of the debug info I have removed is just parsing of a rather large distfile. If you need I can create a very small test case and use that. -- John From rouilj@cs.umb.edu Fri Apr 2 17:22:31 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24010; Fri, 2 Apr 93 17:22:31 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA16524 (5.65c/IDA-1.4.4 for ); Fri, 2 Apr 1993 20:22:23 -0500 Message-Id: <199304030122.AA16524@cs.umb.edu> To: rdist-dev@usc.edu Subject: rdist bug on /. resolved Date: Fri, 02 Apr 1993 20:22:23 -0500 From: "John P. Rouillard" I have applied all of Don's patches to 6.1b1 (sadly they required a bit of hand application). I have just compiled it for my test failure case, and all seems to have been fixed. Mike, should I post my patch that applied Don's patches? -- John -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From mcooper@acamar.usc.edu Fri Apr 2 18:05:54 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25466; Fri, 2 Apr 93 18:05:54 PST Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA12191; Fri, 2 Apr 93 18:05:47 PST Sender: "Michael A. Cooper" Date: Fri, 2 Apr 93 18:05:47 PST From: Michael A. Cooper Reply-To: mcooper@usc.edu To: "John P. Rouillard" Cc: rdist-dev@usc.edu Subject: Re: rdist bug on /. resolved In-Reply-To: Your message of Fri, 02 Apr 1993 20:22:23 -0500 Message-Id: Content-Length: 53 Just send me the diffs to 6.1beta.1. thanks. mike From rouilj@cs.umb.edu Sat Apr 3 08:46:20 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24290; Sat, 3 Apr 93 08:46:20 PST Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA24049 (5.65c/IDA-1.4.4); Sat, 3 Apr 1993 11:46:17 -0500 Message-Id: <199304031646.AA24049@cs.umb.edu> To: mcooper@usc.edu Cc: rdist-dev@usc.edu Subject: Re: rdist bug on /. resolved In-Reply-To: Your message of "Fri, 02 Apr 1993 18:05:47 PST." Date: Sat, 03 Apr 1993 11:46:16 -0500 From: "John P. Rouillard" In message , Michael A. Cooper writes: > Just send me the diffs to 6.1beta.1. thanks. Done. I sent them from sni-usa.com. Note that you had some code bracketed by #ifdef notsure, #endif I removed those designations as I applied the patch. You may wish to put them back in. I really didn't bother checking to see if notsure was defined or not. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Sat Apr 3 15:32:20 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01110; Sat, 3 Apr 93 15:32:20 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11314; Sat, 3 Apr 93 15:31:55 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06163; Sat, 3 Apr 93 15:25:35 PST Message-Id: <9304032325.AA06163@dbeusee.us.oracle.com> Date: Sat, 3 Apr 93 15:25:35 PST From: Don Beusee To: rouilj@sni-usa.com Subject: Re: rest of rdist info Cc: mcooper@usc.edu, rdist-dev@usc.edu Mike, et al, It looks like we have a bug introduced with 6.1.b1 (which I am attempting to compile today to verify). For some reason, sbcmds->sc_name has the same pointer as files->n_next in this case. I don't think this should be happening, and I doubt it happened in 6.1.b0. From rouilj@sni-usa.com Sat Apr 3 14:28:01 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06110; Sat, 3 Apr 93 14:27:59 PST Received: from camus.sni-usa.com by gatekeeper.oracle.com (5.59.11/37.7) id AA08554; Sat, 3 Apr 93 14:34:03 PST Received: by camus.sni-usa.com (5.61/4.7) id AA06231; Sat, 3 Apr 93 17:34:50 -0500 Date: Sat, 3 Apr 93 17:34:50 -0500 From: rouilj@sni-usa.com (John Rouillard) Message-Id: <9304032234.AA06231@camus.sni-usa.com> To: dbeusee@us Subject: rest of rdist info Status: R Sorry no cute shar this time. Each section has ==== signs before it. It looks like the segment of code in docmd.c that if (!sbcmds->sc_name || !*sbcmds->sc_name) { destdir = 0; ddir = 0; } debugmsg(DM_MISC, "Debug sbcmds->sc_name %d, destdir=%d, ddir=%d", files->n_next, destdir, ddir); always forces ddir and destdir to 0. Even in the /. case. I assume that code is supposed to be checking to see if the sc_name pointer is NULL, or if sc_name its itself null. In either of those cases, ddir and destdir are set to 0. === failure binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) except /config/binaries/sinix-i386/usr/etc/*~; install -b /usr/etc; /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/config/binaries/sinix-i386/usr/etc/*~) camus: expand(1003d1a0, 7) start, list = ( /config/binaries/sinix-i386/usr/etc/*~ ) camus: makenl(null) camus: makenl(/usr/etc) camus: expand(1003d1d0, 1) start, list = ( /usr/etc ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1f0, socks, 10045000) start socks: Debug files->n_next= 268685824, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685824, destdir=0, ddir=0 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006174' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc/amd rname=amd dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "512 733872376 755 root sys" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875554 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\001) Msg = "socks: REMOTE ERROR: /usr/rdista002xP -> /usr/etc: rename failed: Is a directory" socks: REMOTE ERROR: /usr/rdista002xP -> /usr/etc: rename failed: Is a directory socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc/amq rname=amq dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\004) Msg = "socks: /usr/etc: updated" socks: /usr/etc: updated socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 0 socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc/mk-amd-map rname=mk-amd-map dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd = Y (\131) Msg = "512 733872376 755 root sys" socks: Y512 733872376 755 root sys socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc/sudo rname=sudo dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 0 socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" === success binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) install -b /usr/etc; cd /config/Distfile/ /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/usr/etc) camus: expand(1003d1b0, 1) start, list = ( /usr/etc ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1d0, socks, 10045000) start socks: Debug files->n_next= 268685792, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685792, destdir=1, ddir=1 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006182' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc rname=amd dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "2485648 731546766 755 rouilj usrother" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875827 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc rname=amq dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd = Y (\131) Msg = "240280 731199433 755 root other" socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 240280 730786718 733872373 root root amq" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amq' 240280 bytes socks: Send file 'amq' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc rname=mk-amd-map dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(mk-amd-map, 8) socks: except(/config/binaries/sinix-i386/usr/etc/mk-amd-map) socks: update(mk-amd-map, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "mk-amd-map" socks: <<< Cmd = Y (\131) Msg = "50636 730786719 755 rouilj usrother" socks: update status mk-amd-map (/config/binaries/sinix-i386/usr/etc/mk-amd-map) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 50636 730786719 733872374 root root mk-amd-map" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'mk-amd-map' 50636 bytes socks: Send file 'mk-amd-map' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc rname=sudo dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd = Y (\131) Msg = "61096 730862981 4111 root usrother" socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 3 socks: >>> Cmd = R (\122) Msg = "10 4111 61096 730862981 733872375 root root sudo" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'sudo' 61096 bytes socks: Send file 'sudo' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" ==== last dot binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) except /config/binaries/sinix-i386/usr/etc/*~; install -b /usr/etc/.; /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/config/binaries/sinix-i386/usr/etc/*~) camus: expand(1003d1a0, 7) start, list = ( /config/binaries/sinix-i386/usr/etc/*~ ) camus: makenl(null) camus: makenl(/usr/etc/.) camus: expand(1003d1d0, 1) start, list = ( /usr/etc/. ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1f0, socks, 10045000) start socks: Debug files->n_next= 268685824, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685824, destdir=0, ddir=0 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006183' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc/amd rname=amd dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "512 733875937 755 root sys" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875927 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\001) Msg = "socks: REMOTE ERROR: /usr/etc/rdista002xb -> /usr/etc/.: rename failed: Invalid argument" socks: REMOTE ERROR: /usr/etc/rdista002xb -> /usr/etc/.: rename failed: Invalid argument socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc/amq rname=amq dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\004) Msg = "socks: /usr/etc/.: updated" socks: /usr/etc/.: updated socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 0 socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc/mk-amd-map rname=mk-amd-map dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd = Y (\131) Msg = "512 733876025 755 root sys" socks: Y512 733876025 755 root sys socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc/sudo rname=sudo dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 0 socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" -- John From dbeusee@us.oracle.com Sat Apr 3 18:04:20 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05178; Sat, 3 Apr 93 18:04:20 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA18756; Sat, 3 Apr 93 18:04:04 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06381; Sat, 3 Apr 93 17:57:44 PST Message-Id: <9304040157.AA06381@dbeusee.us.oracle.com> Date: Sat, 3 Apr 93 17:57:44 PST From: Don Beusee To: rouilj@sni-usa.com Subject: rdist destdir patch for 6.1.b1 Cc: mcooper@usc.edu, rdist-dev@usc.edu Mike, et al, There was a problem with the debug code - which was printing files->n_next when it should have printed sbcmds->sc_name (see the mistake in the note below). I did not catch this until I got gzip and rdist 6.1.b1 compiled and running. John's problem is simplified with the following distfile: *1 -> (myhost1) except *~; install /tmp/rdist; Where a1 and b1 files are in the current directory. If the except is before the install line, sbcmds->sc_name is NULL and destdir will be zero. But if the except line is moved after the install line, then sbcmds->sc_name will not be NULL and destdir will be 1 (as expected). This problem was introduced in 6.1.b1. It looks like the only thing wrong is the way docmd() has assumed the install directive would be first in the sbcmd chain. Here is the debug session: stopped in doarrow at line 391 in file "docmd.c" 391 if (files == NULL) { (dbx) print *sbcmds *`docmd`doarrow`sbcmds = { sc_type = 8 sc_options = 0 sc_name = (nil) sc_args = 0x30810 sc_next = 0x30820 } (dbx) print *sbcmds->sc_next *`docmd`doarrow`sbcmds->sc_next = { sc_type = 6 sc_options = 0 sc_name = 0x30868 "/tmp/rdist" sc_args = (nil) sc_next = (nil) } (dbx) Below is the patch that fixes this problem. Here is a .shar file patch for docmd.c and client.c (apply this to virgin 6.1.b1): #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.docmd.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.1 1993/04/04 00:18:59 X--- client.c 1993/04/04 01:57:28 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 1.1 1993/04/04 00:18:59 dbeusee Exp dbeusee $"; X X static char sccsid[] = "@(#)client.c"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! ": client.c,v 6.52 1993/03/27 23:03:29 mcooper Exp mcooper $"; X X static char sccsid[] = "@(#)client.c"; X X*************** X*** 1023,1031 **** X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int install(src, dest, destdir, opts) X char *src, *dest; X! int destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X--- 1023,1031 ---- X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int install(src, dest, ddir, destdir, opts) X char *src, *dest; X! int ddir, destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X*************** X*** 1083,1088 **** X--- 1083,1089 ---- X if (IS_ON(opts, DO_WHOLE)) { X while (*rname == '/') X rname++; X+ ddir = 1; X destdir = 1; X } else { X rname = strrchr(target, '/'); X*************** X*** 1096,1108 **** X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d\n", X! target, source, rname, dest, destdir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (destdir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); X--- 1097,1109 ---- X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d, ddir=%d\n", X! target, source, rname, dest, destdir, ddir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (ddir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.docmd.c && X*** 1.1 1993/04/04 00:18:49 X--- docmd.c 1993/04/04 01:54:16 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: docmd.c,v 1.1 1993/04/04 00:18:49 dbeusee Exp dbeusee $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! ": docmd.c,v 6.56 1993/03/27 22:28:06 mcooper Exp mcooper $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X*************** X*** 100,106 **** X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO|MT_DEBUG, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X--- 100,106 ---- X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X*************** X*** 381,387 **** X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X--- 381,387 ---- X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, destdir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X*************** X*** 397,402 **** X--- 397,410 ---- X X subcmds = sbcmds; X X+ n = 0; X+ for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { X+ if (sc->sc_type == INSTALL) { X+ n++; X+ break; X+ } X+ } X+ X /* X * destination is a directory if one of the following is true: X * a) more than one name specified on left side of -> directive X*************** X*** 403,419 **** X * b) basename of destination in "install" directive is "." X * (e.g. install /tmp/.;) X * c) name on left side of -> directive is a directory on local system. X */ X ddir = files->n_next != NULL; /* destination is a directory */ X- if (!ddir && sbcmds->sc_name && *sbcmds->sc_name) X- ddir = !strcmp(basename(sbcmds->sc_name), "."); X- #ifdef notsure X if (!ddir) { X struct stat s; X if (lstat(files->n_name, &s) == 0) X! ddir = S_ISDIR(s.st_mode); X! } X! #endif X X if (nflag) X (void) printf("updating host %s\n", rhost); X--- 411,448 ---- X * b) basename of destination in "install" directive is "." X * (e.g. install /tmp/.;) X * c) name on left side of -> directive is a directory on local system. X+ * X+ * We need 2 destdir flags (destdir and ddir) because single directory X+ * source is handled differently. In this case, ddir is 0 (which X+ * tells install() not to send DIRTARGET directive to remote rdistd) X+ * and destdir is 1 (which tells remfilename() how to build the FILE X+ * variables correctly). In every other case, destdir and ddir will X+ * have the same value. X */ X ddir = files->n_next != NULL; /* destination is a directory */ X if (!ddir) { X struct stat s; X+ int isadir; X if (lstat(files->n_name, &s) == 0) X! isadir = S_ISDIR(s.st_mode); X! if (!isadir && sc->sc_name && *sc->sc_name) X! ddir = !strcmp(basename(sc->sc_name),"."); X! destdir = isadir | ddir; X! } else X! destdir = ddir; X! X! debugmsg(DM_MISC, X! "Debug files->n_next= %d, destdir=%d, ddir=%d", X! files->n_next, destdir, ddir); X! X! if (!n || !sc->sc_name || !*sc->sc_name) { X! destdir = 0; X! ddir = 0; X! } X! X! debugmsg(DM_MISC, X! "Debug sc->sc_name=%x, destdir=%d, ddir=%d", X! sc->sc_name, destdir, ddir); X X if (nflag) X (void) printf("updating host %s\n", rhost); X*************** X*** 445,464 **** X continue; X } X found: X! n = 0; X! for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { X! if (sc->sc_type != INSTALL) X! continue; X! n++; X! if (install(f->n_name, sc->sc_name, X! sc->sc_name == NULL ? 0 : ddir, X sc->sc_options) > 0) X ++didupdate; X opts = sc->sc_options; X } X! if (n == 0) X! if (install(f->n_name, (char *) NULL, 0, options) > 0) X ++didupdate; X } X X done: X--- 474,490 ---- X continue; X } X found: X! if (n) { X! if (install(f->n_name, sc->sc_name, ddir, destdir, X sc->sc_options) > 0) X ++didupdate; X opts = sc->sc_options; X } X! else { X! if (install(f->n_name, NULL, ddir, destdir, options) X! > 0) X ++didupdate; X+ } X } X X done: SHAR_EOF chmod 0644 patch.docmd.c || echo "restore of patch.docmd.c fails" exit 0 From rouilj@sni-usa.com Sat Apr 3 14:28:01 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06110; Sat, 3 Apr 93 14:27:59 PST Received: from camus.sni-usa.com by gatekeeper.oracle.com (5.59.11/37.7) id AA08554; Sat, 3 Apr 93 14:34:03 PST Received: by camus.sni-usa.com (5.61/4.7) id AA06231; Sat, 3 Apr 93 17:34:50 -0500 Date: Sat, 3 Apr 93 17:34:50 -0500 From: rouilj@sni-usa.com (John Rouillard) Message-Id: <9304032234.AA06231@camus.sni-usa.com> To: dbeusee@us Subject: rest of rdist info Status: R Sorry no cute shar this time. Each section has ==== signs before it. It looks like the segment of code in docmd.c that if (!sbcmds->sc_name || !*sbcmds->sc_name) { destdir = 0; ddir = 0; } debugmsg(DM_MISC, "Debug sbcmds->sc_name %d, destdir=%d, ddir=%d", files->n_next, destdir, ddir); always forces ddir and destdir to 0. Even in the /. case. I assume that code is supposed to be checking to see if the sc_name pointer is NULL, or if sc_name its itself null. In either of those cases, ddir and destdir are set to 0. === failure binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) except /config/binaries/sinix-i386/usr/etc/*~; install -b /usr/etc; /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/config/binaries/sinix-i386/usr/etc/*~) camus: expand(1003d1a0, 7) start, list = ( /config/binaries/sinix-i386/usr/etc/*~ ) camus: makenl(null) camus: makenl(/usr/etc) camus: expand(1003d1d0, 1) start, list = ( /usr/etc ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1f0, socks, 10045000) start socks: Debug files->n_next= 268685824, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685824, destdir=0, ddir=0 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006174' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc/amd rname=amd dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "512 733872376 755 root sys" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875554 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\001) Msg = "socks: REMOTE ERROR: /usr/rdista002xP -> /usr/etc: rename failed: Is a directory" socks: REMOTE ERROR: /usr/rdista002xP -> /usr/etc: rename failed: Is a directory socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc/amq rname=amq dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\004) Msg = "socks: /usr/etc: updated" socks: /usr/etc: updated socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 0 socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc/mk-amd-map rname=mk-amd-map dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd = Y (\131) Msg = "512 733872376 755 root sys" socks: Y512 733872376 755 root sys socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc/sudo rname=sudo dest='/usr/etc' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 0 socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" === success binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) install -b /usr/etc; cd /config/Distfile/ /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/usr/etc) camus: expand(1003d1b0, 1) start, list = ( /usr/etc ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1d0, socks, 10045000) start socks: Debug files->n_next= 268685792, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685792, destdir=1, ddir=1 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006182' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc rname=amd dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "2485648 731546766 755 rouilj usrother" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875827 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc rname=amq dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd = Y (\131) Msg = "240280 731199433 755 root other" socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 240280 730786718 733872373 root root amq" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amq' 240280 bytes socks: Send file 'amq' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc rname=mk-amd-map dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(mk-amd-map, 8) socks: except(/config/binaries/sinix-i386/usr/etc/mk-amd-map) socks: update(mk-amd-map, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "mk-amd-map" socks: <<< Cmd = Y (\131) Msg = "50636 730786719 755 rouilj usrother" socks: update status mk-amd-map (/config/binaries/sinix-i386/usr/etc/mk-amd-map) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 50636 730786719 733872374 root root mk-amd-map" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'mk-amd-map' 50636 bytes socks: Send file 'mk-amd-map' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc rname=sudo dest='/usr/etc' destdir=1, ddir=1 socks: >>> Cmd = T (\124) Msg = "10 /usr/etc" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd = Y (\131) Msg = "61096 730862981 4111 root usrother" socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 3 socks: >>> Cmd = R (\122) Msg = "10 4111 61096 730862981 733872375 root root sudo" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'sudo' 61096 bytes socks: Send file 'sudo' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" ==== last dot binaries: /config/binaries/sinix-i386/usr/etc/* -> (socks) except /config/binaries/sinix-i386/usr/etc/*~; install -b /usr/etc/.; /u/rouilj/develop/rdist-6.1/src/rdist -D -F -m socks -f /config/Distfile/distfile.base binaries camus: makenl(/config/binaries/sinix-i386/usr/etc/*) camus: makenl(socks) camus: makenl(/config/binaries/sinix-i386/usr/etc/*~) camus: expand(1003d1a0, 7) start, list = ( /config/binaries/sinix-i386/usr/etc/*~ ) camus: makenl(null) camus: makenl(/usr/etc/.) camus: expand(1003d1d0, 1) start, list = ( /usr/etc/. ) camus: makenl(null) camus: insert(binaries, 1003d170, 1003d190, 10045000) start, files = ( /config/binaries/sinix-i386/usr/etc/* ) camus: expand(1003d170, 3) start, list = ( /config/binaries/sinix-i386/usr/etc/* ) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: makenl(null) camus: expand(1003d190, 7) start, list = ( socks ) camus: makenl(null) socks: doarrow(1003d1f0, socks, 10045000) start socks: Debug files->n_next= 268685824, destdir=1, ddir=1 socks: Debug sbcmds->sc_name 268685824, destdir=0, ddir=0 socks: makeconn(socks) socks: updating host socks socks: Created notify temp file '/tmp/rdist006183' socks: port = 514 local user = root remote user = root socks: Command = 'rdistd -S' socks: <<< Cmd = V (\126) Msg = "" socks: >>> Cmd = V (\126) Msg = "6" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: >>> Cmd = c (\143) Msg = "Hcamus" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amd /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/amd src=/config/binaries/sinix-i386/usr/etc/amd rname=amd dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(amd, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amd) socks: update(amd, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amd" socks: <<< Cmd = Y (\131) Msg = "512 733875937 755 root sys" socks: update status amd (/config/binaries/sinix-i386/usr/etc/amd) is 3 socks: >>> Cmd = R (\122) Msg = "10 755 2485648 731546766 733875927 root root amd" socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: Send file 'amd' 2485648 bytes socks: Send file 'amd' complete. socks: >>> Cmd =  (\005) Msg = "" socks: response() start socks: <<< Cmd =  (\001) Msg = "socks: REMOTE ERROR: /usr/etc/rdista002xb -> /usr/etc/.: rename failed: Invalid argument" socks: REMOTE ERROR: /usr/etc/rdista002xb -> /usr/etc/.: rename failed: Invalid argument socks: install -ocompare /config/binaries/sinix-i386/usr/etc/amq /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/amq src=/config/binaries/sinix-i386/usr/etc/amq rname=amq dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\004) Msg = "socks: /usr/etc/.: updated" socks: /usr/etc/.: updated socks: sendit(amq, 8) socks: except(/config/binaries/sinix-i386/usr/etc/amq) socks: update(amq, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "amq" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status amq (/config/binaries/sinix-i386/usr/etc/amq) is 0 socks: install -ocompare /config/binaries/sinix-i386/usr/etc/mk-amd-map /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/mk-amd-map src=/config/binaries/sinix-i386/usr/etc/mk-amd-map rname=mk-amd-map dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd = Y (\131) Msg = "512 733876025 755 root sys" socks: Y512 733876025 755 root sys socks: install -ocompare /config/binaries/sinix-i386/usr/etc/sudo /usr/etc/. socks: install: target=/config/binaries/sinix-i386/usr/etc/sudo src=/config/binaries/sinix-i386/usr/etc/sudo rname=sudo dest='/usr/etc/.' destdir=0, ddir=0 socks: >>> Cmd = t (\164) Msg = "10 /usr/etc/." socks: response() start socks: <<< Cmd =  (\005) Msg = "" socks: recieved ACK socks: sendit(sudo, 8) socks: except(/config/binaries/sinix-i386/usr/etc/sudo) socks: update(sudo, 8, 10010ce8) socks: >>> Cmd = Q (\121) Msg = "sudo" socks: <<< Cmd =  (\005) Msg = "" socks: LOCAL ERROR: update: unexpected response '' socks: update status sudo (/config/binaries/sinix-i386/usr/etc/sudo) is 0 socks: closeconn() called socks: >>> Cmd =  (\002) Msg = "" -- John From dbeusee@us.oracle.com Sat Apr 3 23:55:24 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14104; Sat, 3 Apr 93 23:55:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA04746; Sat, 3 Apr 93 23:55:22 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07186; Sat, 3 Apr 93 23:49:06 PST Message-Id: <9304040749.AA07186@dbeusee.us.oracle.com> Date: Sat, 3 Apr 93 23:49:06 PST From: Don Beusee To: mcooper@usc.edu Subject: patch for remfilename() bug (for 6.1.b1) Cc: rdist-dev@usc.edu Was there something that prompted you to rewrite this routine? There are some problems with the new routine. Here is a patch for a problem where sometimes REMFILE ends with a '/'. I also added a debug message for the install() routine: *** 1.3 1993/04/04 05:18:54 --- client.c 1993/04/04 06:17:59 *************** *** 92,98 **** else { cp = path; cp += strlen(src); ! if (*cp != '/') (void) sprintf(buff, "%s/%s", dest, cp); else (void) sprintf(buff, "%s%s", dest, cp); --- 92,98 ---- else { cp = path; cp += strlen(src); ! if ((*cp != '/') && *cp) (void) sprintf(buff, "%s/%s", dest, cp); else (void) sprintf(buff, "%s%s", dest, cp); *************** *** 1032,1037 **** --- 1032,1040 ---- char *rname; int didupdate = 0; + debugmsg(DM_CALL, + "install(src=%s, dest=%s, ddir=%d, destdir=%d, opts=%d)\n", + (src?src:"NULL"), (dest?dest:"NULL"), ddir, destdir, opts); /* * Save source name */ Also, this new version has extra /.'s in it. Take this debug output for instance: dbeusee: remfilename: src=g dest=/tmp/rdist/. path=g/./g1 rname=g1 destdir=1 dbeusee: remfilename: remote filename=/tmp/rdist/././g1 6.1.b0 is a little better: dbeusee: DEBUG: remfilename: src=g/., dest=g/./g1, path=/tmp/rdist/., rname=g1, destdir=1 dbeusee: DEBUG: remfilename: remote filename=/tmp/rdist/./g1 It looks like the new version removes the /. from src - why does it do that? This seems to happen in install() somewhere. Here is the distfile: g/. -> ${HOST} install /tmp/rdist/. ; Regards, Don. From dbeusee@us.oracle.com Sun Apr 4 01:50:08 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18291; Sun, 4 Apr 93 01:50:08 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA09866; Sun, 4 Apr 93 01:50:06 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07319; Sun, 4 Apr 93 01:43:52 PST Message-Id: <9304040943.AA07319@dbeusee.us.oracle.com> Date: Sun, 4 Apr 93 01:43:52 PST From: Don Beusee To: rdist-dev@usc.edu Subject: os-type problems/patch os-type assumes that uname -s returns the o/s on all platforms. This is not the case. This patch uses /etc/motd first (more reliable). This patch also includes a new platform "ftx" (stratus svr4). Also, the "filesystem" checks now exclude sunos4, since /usr/bin/cat is on most systems, which we would want "unknown" to be returned (since it is not handled above the f/s checks). Here is the new os-type file: #!/bin/sh # # Copyright (c) 1989 Jan-Simon Pendry # Copyright (c) 1989 Imperial College of Science, Technology & Medicine # Copyright (c) 1989 The Regents of the University of California. # All rights reserved. # # This code is derived from software contributed to Berkeley by # Jan-Simon Pendry at Imperial College, London. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by the University of # California, Berkeley and its contributors. # 4. Neither the name of the University nor the names of its contributors # may be used to endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # %W% (Berkeley) %G% # # $Id: os-type,v 1.1 1993/04/04 09:22:33 dbeusee Exp dbeusee $ # # # Take a pot-shot at your os type # OS="" # # Try poking around in /etc/motd # case "`exec 2>/dev/null; head -2 /etc/motd`" in *"Sun UNIX 4.2 Release 3."*) OS=sunos3;; *"SunOS Release 4."*) OS=sunos4;; *"SunOS 5."*) OS=sunos5;; *"HP-UX on the HP"*) OS=hpux;; *"DYNIX(R)"*) OS=dynix;; *"DYNIX/ptx"*) OS=dynixptx;; *" dcosx "*) OS=dcosx;; *"Ultrix V2."*) OS=ultrix2_2;; *"Ultrix V3."*) OS=ultrix3_0;; *"Ultrix-32 V3."*) OS=ultrix3_0;; *"Ultrix Worksystem V2."*) OS=ultrix3_0;; *"ULTRIX V4.2"*) OS=ultrix4;; *"ULTRIX V4."*) OS=ultrix4;; *"HLH OTS Version 1."*) OS=hlh42;; *"RISC iX release 1."*) OS=riscix;; *"FPX 4."*) OS=fpx4;; *"HCX/UX"*) OS=hcx;; *"4.4 BSD UNIX"*) OS=bsd44;; *"4.3 BSD Reno UNIX"*) OS=bsd44;; *"4.3 BSD UNIX"*) if [ -f /etc/minidisk ]; then OS=acis43 elif [ -f /sbin/nfsiod ]; then OS=bsd44 # prototype else OS=xinu43 fi;; *"Alliant Concentrix"*) OS=concen;; *"Umax 4.3"*) OS=umax43;; *"RISCos 4"*) OS=mipsos4;; *"DEC OSF/1"*) OS=osf1;; *"Multiflow 4.3 BSD"*) OS=tracebsd;; *) if [ -f /version ]; then OS=ftx else # # try uname # if [ -f /usr/bin/uname ]; then uname=/usr/bin/uname fi if [ ! -z "${uname}" ]; then osname="`exec 2>/dev/null; ${uname} -s | tr '[A-Z]' '[a-z]'`" osver="`exec 2>/dev/null; ${uname} -r`" osmajver="`exec 2>/dev/null; echo $osver | sed -e 's;\..*;;'`" case "${osname}${osver}" in "ultrix"*) OS="${osname}${osmajver}";; "sunos"*) OS="${osname}${osmajver}";; "aix"*) osmajver="`${uname} -v`" OS="${osname}${osmajver}" ;; *) OS="${osname}${osver}";; esac fi fi ;; esac if [ -z "${OS}" ]; then # # Well, that didn't work so apply some heuristics # to the filesystem name space... # # echo "# ... inspecting File system ..." >&2 if [ -f /etc/comply ]; then OS=utek elif [ -d /usr/lib/methods -o -d /etc/methods ]; then OS=aix3 elif [ -f /etc/nd ]; then OS=sunos3 elif [ -f /etc/elcsd ]; then echo "# ... Ultrix - assuming U4.0 ..." >&2 OS=ultrix4 elif [ -f /hp-ux ]; then OS=hpux elif [ -f /etc/ttylocal ]; then OS=xinu43 elif [ -f /etc/minidisk ]; then OS=acis43 elif [ -f /etc/toolboxdaemon ]; then OS=aux elif [ -f /sbin/nfsiod ]; then OS=bsd44 elif [ -d /vrm ]; then OS=aix2 elif [ -f /dynix ]; then OS=dynix elif [ -f /bin/pyr ] && /bin/pyr; then OS=pyrosx elif [ -d /NextApps ]; then OS=next elif [ -f /etc/gl/ucode ]; then OS=irix3 elif [ -d /usr/gfx/ucode ]; then OS=irix4 elif [ -f /stellix ]; then OS=stellix else case "`(sh ../config/arch)2>/dev/null`" in ibm032) OS=acis43;; aviion) OS=dgux;; *) OS=unknown;; esac fi fi # ${OS} echo "" >&2 echo " OS appears to be \"${OS}\"" >&2 echo "" >&2 echo "${OS}" exit 0 From dbeusee@us.oracle.com Sun Apr 4 18:04:08 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07824; Sun, 4 Apr 93 18:04:08 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA19158; Sun, 4 Apr 93 18:04:07 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08365; Sun, 4 Apr 93 17:57:52 PDT Message-Id: <9304050057.AA08365@dbeusee.us.oracle.com> Date: Sun, 4 Apr 93 17:57:52 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: FTX files Here is config/mf.ftx and config/os-ftx.h (this is for stratus svr4 platform, which they call FTX). This is for 6.1.b1. It is identical to pyramid's dc/osx. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # config/mf.ftx # config/os-ftx.h # sed 's/^X//' << 'SHAR_EOF' > config/mf.ftx && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.ftx,v 6.0 1993/02/20 23:36:21 mcooper Exp $ X# X X# X# ftx Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strcasecmp.o $(O)regex.o $(O)strtol.o $(O)hasmntopt.o X X# X# System libraries that we need to load. X# XLIB_SYS = -lnsl -lsocket -lc /usr/ucblib/libucb.a X X# X# No ranlib X# XRANLIB = SHAR_EOF chmod 0644 config/mf.ftx || echo "restore of config/mf.ftx fails" sed 's/^X//' << 'SHAR_EOF' > config/os-ftx.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-ftx.h,v 6.1 1993/03/20 21:28:37 mcooper Exp mcooper $ X * @(#)os-ftx.h X */ X X/* X * System V Release 4 (ftx) X */ X#include "os-svr4.h" X X/* X * Signal that can be used to test whether an rdist child process X * is still running. This should be a signal that is not used for X * anything else. On most systems, SIGUSR1 is appropriate. X */ X#define TEST_SIGNAL SIGUSR1 SHAR_EOF chmod 0644 config/os-ftx.h || echo "restore of config/os-ftx.h fails" exit 0 From dbeusee@us.oracle.com Mon Apr 5 01:37:24 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20189; Mon, 5 Apr 93 01:37:24 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11435; Mon, 5 Apr 93 01:34:56 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08786; Mon, 5 Apr 93 01:28:40 PDT Message-Id: <9304050828.AA08786@dbeusee.us.oracle.com> Date: Mon, 5 Apr 93 01:28:40 PDT From: Don Beusee To: mcooper@usc.edu, rouilj@ra.cs.umb.edu Subject: Jumbo destdir patch for 6.1.b1 (replaces previous b1 patches) Cc: rdist-dev@usc.edu I did more research and found that it was caused by the patch. I thought I had a 6.1.b0 compiled without the patch, but I didn't. I printed docmd.c and studied the doarrow() routine more carefully and I have developed a new patch for virgin 6.1.b1 to fix all known problems with the previous destdir patches to date. Here is the shar file for docmd.c, client.c, & defs.h (jumbo destdir patch): #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # patch.client.c # patch.defs.h # patch.docmd.c # sed 's/^X//' << 'SHAR_EOF' > patch.client.c && X*** 1.1 1993/04/04 00:18:59 X--- src/client.c 1993/04/05 07:28:02 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: client.c,v 1.1 1993/04/04 00:18:59 dbeusee Exp $"; X X static char sccsid[] = "@(#)client.c"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! ": client.c,v 6.52 1993/03/27 23:03:29 mcooper Exp mcooper $"; X X static char sccsid[] = "@(#)client.c"; X X*************** X*** 92,98 **** X else { X cp = path; X cp += strlen(src); X! if (*cp != '/') X (void) sprintf(buff, "%s/%s", dest, cp); X else X (void) sprintf(buff, "%s%s", dest, cp); X--- 92,98 ---- X else { X cp = path; X cp += strlen(src); X! if ((*cp != '/') && *cp) X (void) sprintf(buff, "%s/%s", dest, cp); X else X (void) sprintf(buff, "%s%s", dest, cp); X*************** X*** 145,154 **** X if (IS_ON(opts, DO_VERIFY)) X continue; X (void) sendcmd(C_SPECIAL, X! "%s=%s;%s=%s;export %s %s;%s", X E_LOCFILE, starget, X E_REMFILE, rfile, X! E_LOCFILE, E_REMFILE, X sc->sc_name); X while (response() > 0) X ; X--- 145,155 ---- X if (IS_ON(opts, DO_VERIFY)) X continue; X (void) sendcmd(C_SPECIAL, X! "%s=%s;%s=%s;%s=%s;export %s %s %s;%s", X E_LOCFILE, starget, X E_REMFILE, rfile, X! E_BASEFILE, basename(rfile), X! E_LOCFILE, E_REMFILE, E_BASEFILE, X sc->sc_name); X while (response() > 0) X ; X*************** X*** 1023,1036 **** X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int install(src, dest, destdir, opts) X char *src, *dest; X! int destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X int didupdate = 0; X X /* X * Save source name X */ X--- 1024,1040 ---- X * Return 0 if nothing updated. X * Return > 0 if something was updated. X */ X! extern int install(src, dest, ddir, destdir, opts) X char *src, *dest; X! int ddir, destdir, opts; X { X static char destcopy[MAXPATHLEN]; X char *rname; X int didupdate = 0; X X+ debugmsg(DM_CALL, X+ "install(src=%s,dest=%s,ddir=%d,destdir=%d,opts=%d) start\n", X+ (src?src:"NULL"), (dest?dest:"NULL"), ddir, destdir, opts); X /* X * Save source name X */ X*************** X*** 1083,1088 **** X--- 1087,1093 ---- X if (IS_ON(opts, DO_WHOLE)) { X while (*rname == '/') X rname++; X+ ddir = 1; X destdir = 1; X } else { X rname = strrchr(target, '/'); X*************** X*** 1096,1108 **** X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d\n", X! target, source, rname, dest, destdir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (destdir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); X--- 1101,1113 ---- X } X X debugmsg(DM_MISC, X! "install: target=%s src=%s rname=%s dest='%s' destdir=%d, ddir=%d\n", X! target, source, rname, dest, destdir, ddir); X X /* X * Pass the destination file/directory name to remote. X */ X! if (ddir) X (void) sendcmd(C_DIRTARGET, "%o %s", opts, dest); X else X (void) sendcmd(C_TARGET, "%o %s", opts, dest); SHAR_EOF chmod 0644 patch.client.c || echo "restore of patch.client.c fails" sed 's/^X//' << 'SHAR_EOF' > patch.defs.h && X*** 1.1 1993/04/04 02:15:36 X--- include/defs.h 1993/04/04 05:19:27 X*************** X*** 34,40 **** X */ X X /* X! * $Id: defs.h,v 1.1 1993/04/04 02:15:36 dbeusee Exp $ X * @(#)defs.h 5.2 (Berkeley) 3/20/86 X */ X X--- 34,40 ---- X */ X X /* X! * $Id: defs.h,v 1.2 1993/04/04 05:19:17 dbeusee Exp $ X * @(#)defs.h 5.2 (Berkeley) 3/20/86 X */ X X*************** X*** 246,251 **** X--- 246,252 ---- X #define E_FILES "FILES" /* List of files */ X #define E_LOCFILE "FILE" /* Local Filename */ X #define E_REMFILE "REMFILE" /* Remote Filename */ X+ #define E_BASEFILE "BASEFILE" /* basename of Remote File */ X X /* X * Suffix to use when saving files SHAR_EOF chmod 0644 patch.defs.h || echo "restore of patch.defs.h fails" sed 's/^X//' << 'SHAR_EOF' > patch.docmd.c && X*** 1.1 1993/04/04 00:18:49 X--- src/docmd.c 1993/04/05 08:19:06 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: docmd.c,v 1.1 1993/04/04 00:18:49 dbeusee Exp $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! ": docmd.c,v 6.56 1993/03/27 22:28:06 mcooper Exp mcooper $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X*************** X*** 100,106 **** X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO|MT_DEBUG, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X--- 100,106 ---- X return; X X if (!IS_ON(options, DO_QUIET)) { X! message(MT_INFO, "notify %s%s %s", X (rhost) ? "@" : "", X (rhost) ? rhost : "", getnlstr(to)); X } X*************** X*** 381,387 **** X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X--- 381,387 ---- X register struct namelist *f; X register struct subcmd *sc; X register char **cpp; X! int n, ddir, destdir, opts = options; X struct namelist *files = cmd->c_files; X struct subcmd *sbcmds = cmd->c_cmds; X char *rhost = cmd->c_name; X*************** X*** 395,420 **** X return; X } X X- subcmds = sbcmds; X- X- /* X- * destination is a directory if one of the following is true: X- * a) more than one name specified on left side of -> directive X- * b) basename of destination in "install" directive is "." X- * (e.g. install /tmp/.;) X- * c) name on left side of -> directive is a directory on local system. X- */ X- ddir = files->n_next != NULL; /* destination is a directory */ X- if (!ddir && sbcmds->sc_name && *sbcmds->sc_name) X- ddir = !strcmp(basename(sbcmds->sc_name), "."); X- #ifdef notsure X- if (!ddir) { X- struct stat s; X- if (lstat(files->n_name, &s) == 0) X- ddir = S_ISDIR(s.st_mode); X- } X- #endif X- X if (nflag) X (void) printf("updating host %s\n", rhost); X else { X--- 395,400 ---- X*************** X*** 437,442 **** X--- 417,468 ---- X } X } X X+ subcmds = sbcmds; X+ X+ n = 0; X+ for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { X+ if (sc->sc_type != INSTALL) X+ continue; X+ n++; X+ /* X+ * destination is a directory if one of the following is true: X+ * a) more than one name specified on left side of -> directive X+ * b) basename of destination in "install" directive is "." X+ * (e.g. install /tmp/.;) X+ * c) name on left side of -> directive is a directory on local system. X+ * X+ * We need 2 destdir flags (destdir and ddir) because single directory X+ * source is handled differently. In this case, ddir is 0 (which X+ * tells install() not to send DIRTARGET directive to remote rdistd) X+ * and destdir is 1 (which tells remfilename() how to build the FILE X+ * variables correctly). In every other case, destdir and ddir will X+ * have the same value. X+ */ X+ ddir = files->n_next != NULL; /* destination is a directory */ X+ if (!ddir) { X+ struct stat s; X+ int isadir; X+ if (lstat(files->n_name, &s) == 0) X+ isadir = S_ISDIR(s.st_mode); X+ if (!isadir && sc->sc_name && *sc->sc_name) X+ ddir = !strcmp(basename(sc->sc_name),"."); X+ destdir = isadir | ddir; X+ } else X+ destdir = ddir; X+ X+ debugmsg(DM_MISC, X+ "Debug files->n_next= %d, destdir=%d, ddir=%d", X+ files->n_next, destdir, ddir); X+ X+ if (!sc->sc_name || !*sc->sc_name) { X+ destdir = 0; X+ ddir = 0; X+ } X+ X+ debugmsg(DM_MISC, X+ "Debug sc->sc_name=%x, destdir=%d, ddir=%d", X+ sc->sc_name, destdir, ddir); X+ X for (f = files; f != NULL; f = f->n_next) { X if (filev) { X for (cpp = filev; *cpp; cpp++) X*************** X*** 445,464 **** X continue; X } X found: X! n = 0; X! for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { X! if (sc->sc_type != INSTALL) X! continue; X! n++; X! if (install(f->n_name, sc->sc_name, X! sc->sc_name == NULL ? 0 : ddir, X! sc->sc_options) > 0) X! ++didupdate; X! opts = sc->sc_options; X! } X! if (n == 0) X! if (install(f->n_name, (char *) NULL, 0, options) > 0) X! ++didupdate; X } X X done: X--- 471,490 ---- X continue; X } X found: X! if (install(f->n_name, sc->sc_name, ddir, destdir, X! sc->sc_options) > 0) X! ++didupdate; X! opts = sc->sc_options; X! } X! X! } /* end loop for each INSTALL command */ X! X! /* if no INSTALL commands present, do default install */ X! if (!n) { X! /* ddir & destdir set to zero for default intsall */ X! if (install(f->n_name, NULL, 0, 0, options) X! > 0) X! ++didupdate; X } X X done: SHAR_EOF chmod 0644 patch.docmd.c || echo "restore of patch.docmd.c fails" exit 0 From rouilj@cs.umb.edu Sun Apr 4 08:32:55 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08031; Sun, 4 Apr 93 08:32:54 PDT Received: from cs.umb.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA21733; Sun, 4 Apr 93 08:39:05 PDT Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA10267 (5.65c/IDA-1.4.4 for ); Sun, 4 Apr 1993 11:39:01 -0400 Message-Id: <199304041539.AA10267@cs.umb.edu> To: mcooper@usc.edu Cc: dbeusee@us Subject: Hmm breakage in 6.1b1 with patch Date: Sun, 04 Apr 1993 10:38:58 -0500 From: "John P. Rouillard" Status: R I use the following rule to create three directories (/etc/amd, /depot, /project), and enforce the permission on them: /foo/.directory -> (${AMD_HOSTS}) install /etc/amd; install /depot; install /project; This morning I noticed that it wasn't working. I get the install of /etc/amd but not any of the others. I am not positive that this was working with a virgin 6.1b1, but I know it was working with 6.1b0. Any ideas/confirmations? The workaround is to split it across three rules, but from an esthetic viewpoint, I would rather not have to do that. -- John John Rouillard Consulting Systems Programmer Siemens-Nixdorf USA Burlington, MA rouilj@sni-usa.com (617) 273-2687 x-3498 Special Projects Volunteer University of Massachusetts at Boston Boston, MA rouilj@cs.umb.edu (preferred address) (617) 287-6480 Consulting Systems Programmer Boston College, Institute for Space Research Bedford, MA rouilj@dl5000.bc.edu (617) 552-8793 =============================================================================== My employers don't acknowledge my existence much less my opinions. From aad@siemens.siemens.com Tue Apr 6 13:01:53 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25611; Tue, 6 Apr 93 13:01:53 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0ngJq7-0019NuC; Tue, 6 Apr 93 16:01 EDT Received: by lovecraft (4.1/SMI-4.1) id AA16699; Tue, 6 Apr 93 16:01:46 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Tue, 6 Apr 1993 16:01:45 -0400 (EDT) Message-Id: Date: Tue, 6 Apr 1993 16:01:45 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev-list@lovecraft.siemens.com Subject: Sun 4/SunOS 4.1.1 optimization gotcha I just built 6.1.b1 with dbeusee's recent jumbo patch. Compilation was done on a Sun 4 under SunOS 4.1.1 with the bundled compiler; execution was on a Sun4c disting to a Sun4c and a Sun4m, both running 4.1.3. Disting a single file on the commandline resulted in: <=>derleth<=>.s rdist -c /tmp/.kludge lovecraft: Password: lovecraft: updating host lovecraft lovecraft: LOCAL ERROR: Segmentation violation - dumping core [PID = 15986, amchild] I rebuilt without -O, and the problem went away. Even with -O, though, rdisting out of Distfile worked just fine. Optimization bug? I can't say. The only 4.1.1 optimization but I recall is with Ghostscript's iscan.c. The 4.1.3 optimizer or gcc might not produce the problem; I haven't tested. I also can't say if the problem lies in 6.1b1, or in the good Herr Beusee's patches. ======================================================================8--< From dbeusee@us.oracle.com Tue Apr 6 21:49:00 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12714; Tue, 6 Apr 93 21:49:00 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA13739; Tue, 6 Apr 93 21:48:58 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA15108; Tue, 6 Apr 93 21:42:42 PDT Message-Id: <9304070442.AA15108@dbeusee.us.oracle.com> Date: Tue, 6 Apr 93 21:42:42 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: rdist patch to fix jumbo destdir patch core dump I found one case where the jumbo destdir patch causes a core dump. This patch fixes that. Apply this one after applying the jumbo destdir patch. This patch is for docmd.c: *** 1.3 1993/04/05 13:36:14 --- src/docmd.c 1993/04/07 03:11:35 *************** *** 481,490 **** /* if no INSTALL commands present, do default install */ if (!n) { ! /* ddir & destdir set to zero for default intsall */ ! if (install(f->n_name, NULL, 0, 0, options) ! > 0) ! ++didupdate; } done: --- 481,499 ---- /* if no INSTALL commands present, do default install */ if (!n) { ! for (f = files; f != NULL; f = f->n_next) { ! if (filev) { ! for (cpp = filev; *cpp; cpp++) ! if (strcmp(f->n_name, *cpp) == 0) ! goto found2; ! continue; ! } ! found2: ! /* ddir & destdir set to zero for default install */ ! if (install(f->n_name, NULL, 0, 0, options) ! > 0) ! ++didupdate; ! } } done: From dbeusee@us.oracle.com Wed Apr 7 08:26:31 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01774; Wed, 7 Apr 93 08:26:31 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA16668; Wed, 7 Apr 93 08:04:43 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA17055; Wed, 7 Apr 93 07:58:29 PDT Message-Id: <9304071458.AA17055@dbeusee.us.oracle.com> Date: Wed, 7 Apr 93 07:58:29 PDT From: Don Beusee To: mcooper@usc.edu Subject: remfilename() patch Cc: rdist-dev@usc.edu The remfilename() in 6.1.b1 is pretty buggy. 1. It does not consider destdir, so things like: dir -> host install newdir; special "chmod 755 $REMFILE"; do not work correctly, because REMFILE ends up with dir/newdir/file. 2. It uses local filename instead of remote filename, so things like: x -> host install /tmp/y; special "chmod 755 $REMFILE"; do not work correctly, because REMFILE ends up with x. If $REMFILE has the correct value, the hardlink code should work correctly too. This patch fixes the above problems. Apply this to client.c: *** 1.5 1993/04/05 13:35:05 --- src/client.c 1993/04/07 14:58:09 *************** *** 80,87 **** "remfilename: src=%s dest=%s path=%s rname=%s destdir=%d\n", A(src), A(dest), A(path), A(rname), destdir); ! if (!dest) return(path); buff[0] = CNULL; lname = buff; --- 80,94 ---- "remfilename: src=%s dest=%s path=%s rname=%s destdir=%d\n", A(src), A(dest), A(path), A(rname), destdir); ! if (!dest) { ! debugmsg(DM_MISC, "remfilename: remote filename=%s\n", path); return(path); + } + + if (!destdir) { + debugmsg(DM_MISC, "remfilename: remote filename=%s\n", dest); + return(dest); + } buff[0] = CNULL; lname = buff; *************** *** 88,94 **** if (path && *path) { cp = strrchr(path, '/'); if (cp == NULL) ! (void) strcpy(lname, path); else { cp = path; cp += strlen(src); --- 95,101 ---- if (path && *path) { cp = strrchr(path, '/'); if (cp == NULL) ! (void) sprintf(buff, "%s/%s", dest, path); else { cp = path; cp += strlen(src); *************** *** 1040,1056 **** */ if (IS_ON(opts, DO_WHOLE)) source[0] = CNULL; ! else { ! char *cp; ! (void) strcpy(source, src); - if (destdir) { - if ((cp = strrchr(source, '/')) == NULL) - source[0] = CNULL; - else - *cp = CNULL; - } - } if (dest == NULL) { FLAG_OFF(opts, DO_WHOLE); /* WHOLE only useful if renaming */ --- 1047,1054 ---- */ if (IS_ON(opts, DO_WHOLE)) source[0] = CNULL; ! else (void) strcpy(source, src); if (dest == NULL) { FLAG_OFF(opts, DO_WHOLE); /* WHOLE only useful if renaming */ From dbeusee@us.oracle.com Thu Apr 22 14:24:21 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09141; Thu, 22 Apr 93 14:24:21 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA18230; Thu, 22 Apr 93 14:24:17 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03895; Thu, 22 Apr 93 14:18:07 PDT Message-Id: <9304222118.AA03895@dbeusee.us.oracle.com> Date: Thu, 22 Apr 93 14:18:07 PDT From: Don Beusee To: mcooper@usc.edu Subject: rdist v6 problems Cc: rdist-dev@usc.edu Rdist V6.1.b1 has a big problem. Some hosts are not getting updated via my automatic nightly cron job: rdisting mail-aliases-noyp package in /usr/lib/mailer/aliases ./rdist.noyp hosts="\ ap1pyr ap2pyr ap4seq dvlseq helpseq wrpyr4 erpyr erpyr3 erseq erseq5 mmsdev \ afhp af1hp af2hp af3hp af4hp af5hp af6hp af7hp af8hp af9hp af10hp af11hp \ ap1seq ap2seq appseq cvcseq dcpyr dmdseq hqpyr1 hqseq kr1seq kr2seq mailseq \ misseq1 olsseq ouseq prodseq1 prodseq2 qaseq supseq supseq2 usoseq wrpyr \ wrpyr2 wrpyr3 wrseq wrseq3 oldwrseq" rdist -h -b -f aliases.rdist -d HOSTS="($hosts)" dvlseq: updating host dvlseq ap4seq: updating host ap4seq ap2pyr: updating host ap2pyr ap1pyr: updating host ap1pyr wrpyr4: updating host wrpyr4 erpyr: updating host erpyr erpyr3: updating host erpyr3 erseq: updating host erseq erseq5: updating host erseq5 mmsdev: updating host mmsdev afhp: updating host afhp af1hp: updating host af1hp af2hp: updating host af2hp af3hp: updating host af3hp af4hp: updating host af4hp af5hp: updating host af5hp af6hp: updating host af6hp af7hp: updating host af7hp af8hp: updating host af8hp af9hp: updating host af9hp af10hp: updating host af10hp af11hp: updating host af11hp ap1seq: updating host ap1seq ap2seq: updating host ap2seq appseq: updating host appseq cvcseq: updating host cvcseq dcpyr: updating host dcpyr dmdseq: updating host dmdseq hqpyr1: updating host hqpyr1 hqseq: updating host hqseq kr1seq: updating host kr1seq kr2seq: updating host kr2seq mailseq: updating host mailseq misseq1: updating host misseq1 olsseq: updating host olsseq ouseq: updating host ouseq prodseq1: updating host prodseq1 prodseq2: updating host prodseq2 qaseq: updating host qaseq supseq: updating host supseq supseq2: updating host supseq2 usoseq: updating host usoseq wrpyr: updating host wrpyr wrpyr2: updating host wrpyr2 wrseq3: updating host wrseq3 oldwrseq: updating host oldwrseq Notice that 2 systems were not updated (helpseq & wrseq). Whats going on? If I use -n, it seems to always show all hosts. Regards, Don. From dpk@fid.morgan.com Thu Apr 22 16:27:59 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12781; Thu, 22 Apr 93 16:27:59 PDT Received: from Morgan.COM ([138.20.3.17]) by gateway.morgan.com with SMTP id <41389>; Thu, 22 Apr 1993 19:27:41 -0400 Received: from foreign.Morgan.COM by Morgan.COM id AA29460; Thu, 22 Apr 93 19:27:31 EDT Date: Thu, 22 Apr 1993 19:27:31 -0400 From: dpk@fid.Morgan.COM (Doug Kingston) Message-Id: <9304222327.AA29460@Morgan.COM> To: rdist-dev@usc.edu Subject: return codes from rdist Cc: donner@gateway.morgan.com, dpk@gateway.morgan.com One of my users made a valid complaint to me that brought up the general issue of exit codes from rdist (and other programs). If rdist fails to make a connection to a remote machine in a command like "rdist -c files .. host:directory", it still exits with exit status 0. In this case it should exit with some non-zero status. Some serious thought should be give to making the exit status values from rdist meaningful and consistent. For example, 0 should mean that every host was contacted and is, or was made up to date. Various other values could indicate types of errors (local parsing/usage error, one or more connections failed, one or more remote errors) perhaps using a bitmap. -Doug- From john@wpi.WPI.EDU Tue Apr 27 12:04:07 1993 Return-Path: Received: from bigboote.WPI.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22373; Tue, 27 Apr 93 12:04:07 PDT Received: from sekrit.WPI.EDU by bigboote.WPI.EDU (ALPHA-6.55/6.12) id PAA26184; Tue, 27 Apr 1993 15:04:03 -0400 From: John Stoffel Received: from localhost by sekrit.WPI.EDU (ALPHA-6.55/6.12) id PAA03604; Tue, 27 Apr 1993 15:04:01 -0400 Date: Tue, 27 Apr 1993 15:04:01 -0400 Message-Id: <199304271904.PAA03604@sekrit.WPI.EDU> To: rdist-dev@usc.edu Subject: using rdist in a cron job Here at WPI, we use rdist (6.0.0) in a cron job that runs every night to update two binary file servers from the master binary file server. I've tried to make it so that rdist doesn't send ANY output to stdout, but instead sends all output using notify. Unfortunately, it doesn't seem to work. I've been looking into adding a new type of 'none' to the logopts, so you can specify that a certain facility WILL NOT produce any output. I'd like to be able to use: rdist -f mydistfile -l stdout=none;notify=all -o... so I don't get any mail from the cron demon at night. This way all status messages would get send through mail, which I could then peruse at my leasure. Has anyone else done something like this? I'm willing to take a stab at it if people think this would be a worth while endeavour. John From neal@ctd.comsat.com Tue Apr 27 12:16:57 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22726; Tue, 27 Apr 93 12:16:57 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nnv94-0003TdC; Tue, 27 Apr 93 15:16 EDT Message-Id: Date: Tue, 27 Apr 93 15:16 EDT From: neal@ctd.comsat.com (Neal Becker) To: John Stoffel Cc: rdist-dev@usc.edu Subject: using rdist in a cron job In-Reply-To: <199304271904.PAA03604@sekrit.WPI.EDU> References: <199304271904.PAA03604@sekrit.WPI.EDU> Here's my crontab entry: 0 0 * * * rdist -f /local/rdist/distfile -l syslog=change,notice,nerror,ferror,warning > /dev/null >>>>> On Tue, 27 Apr 1993 15:04:01 -0400, John Stoffel said: John> Here at WPI, we use rdist (6.0.0) in a cron job that runs every night John> to update two binary file servers from the master binary file server. John> I've tried to make it so that rdist doesn't send ANY output to stdout, John> but instead sends all output using notify. Unfortunately, it doesn't John> seem to work. John> I've been looking into adding a new type of 'none' to the logopts, so John> you can specify that a certain facility WILL NOT produce any output. John> I'd like to be able to use: John> rdist -f mydistfile -l stdout=none;notify=all -o... John> so I don't get any mail from the cron demon at night. This way all John> status messages would get send through mail, which I could then peruse John> at my leasure. Has anyone else done something like this? I'm willing John> to take a stab at it if people think this would be a worth while John> endeavour. John> John From rsalz@osf.org Tue Apr 27 12:20:22 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22823; Tue, 27 Apr 93 12:20:22 PDT Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24326; Tue, 27 Apr 93 15:20:21 -0400 Received: by earth.osf.org (5.65/4.7) id AA14116; Tue, 27 Apr 93 15:20:19 -0400 Date: Tue, 27 Apr 93 15:20:19 -0400 From: rsalz@osf.org Message-Id: <9304271920.AA14116@earth.osf.org> To: john@wpi.WPI.EDU, rdist-dev@usc.edu Subject: Re: using rdist in a cron job Any reason why ">/dev/null" doesn't do it? From aad@siemens.siemens.com Tue Apr 27 12:25:00 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22896; Tue, 27 Apr 93 12:25:00 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0nnvGw-0019RPC; Tue, 27 Apr 93 15:24 EDT Received: by lovecraft (4.1/SMI-4.1) id AA11376; Tue, 27 Apr 93 15:24:53 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Tue, 27 Apr 1993 15:24:53 -0400 (EDT) Message-Id: Date: Tue, 27 Apr 1993 15:24:53 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, John Stoffel Subject: Re: using rdist in a cron job In-Reply-To: <199304271904.PAA03604@sekrit.WPI.EDU> References: <199304271904.PAA03604@sekrit.WPI.EDU> Assuming that your cron lets you specify pipelines, why not just have the crontab run rdist -foo -f | mai john ? ======================================================================8--< From sboyle@wv.MENTORG.COM Tue Apr 27 12:53:00 1993 Return-Path: Received: from mgc.mentorg.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23668; Tue, 27 Apr 93 12:53:00 PDT Received: from wv.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA25876; Tue, 27 Apr 93 12:50:41 -0700 Received: from em-wv03.mentorg.com by wv.MENTORG.COM (5.65c/CF3.4) id AA27391; Tue, 27 Apr 1993 12:50:40 -0700 Received: from porkface.mentorg.com by em-wv03.MENTORG.COM (4.1/CF3.4) id AA29706; Tue, 27 Apr 93 12:50:39 PDT Received: by porkface.mentorg.com (1.37.109.4/CF3.4) id AA16174; Tue, 27 Apr 93 12:50:38 -0700 Message-Id: <9304271950.AA16174@porkface.mentorg.com> From: sboyle@wv.MENTORG.COM (Sean Boyle) Date: Tue, 27 Apr 1993 12:50:37 -0700 X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rdist-dev@usc.edu Subject: crontab entry How about making that ... > /dev/null 2>&1 On Apr 27, 15:16, Neal Becker wrote: } Subject: using rdist in a cron job From neal@ctd.comsat.com Tue Apr 27 12:45:56 1993 Received: from wv.MENTORG.COM by em-wv03.MENTORG.COM (4.1/CF3.4) id AA29649; Tue, 27 Apr 93 12:45:54 PDT Received: from mgc.mentorg.com by wv.MENTORG.COM (5.65c/CF3.4) id AA27291; Tue, 27 Apr 1993 12:45:53 -0700 Received: from usc.edu by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA25792; Tue, 27 Apr 93 12:45:46 -0700 Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22726; Tue, 27 Apr 93 12:16:57 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nnv94-0003TdC; Tue, 27 Apr 93 15:16 EDT Message-Id: Date: Tue, 27 Apr 93 15:16 EDT From: neal@ctd.comsat.com (Neal Becker) To: John Stoffel Cc: rdist-dev@usc.edu Subject: using rdist in a cron job In-Reply-To: <199304271904.PAA03604@sekrit.WPI.EDU> References: <199304271904.PAA03604@sekrit.WPI.EDU> Status: OR Here's my crontab entry: 0 0 * * * rdist -f /local/rdist/distfile -l syslog=change,notice,nerror,ferror,warning > /dev/null >>>>> On Tue, 27 Apr 1993 15:04:01 -0400, John Stoffel said: John> Here at WPI, we use rdist (6.0.0) in a cron job that runs every night John> to update two binary file servers from the master binary file server. John> I've tried to make it so that rdist doesn't send ANY output to stdout, John> but instead sends all output using notify. Unfortunately, it doesn't John> seem to work. John> I've been looking into adding a new type of 'none' to the logopts, so John> you can specify that a certain facility WILL NOT produce any output. John> I'd like to be able to use: John> rdist -f mydistfile -l stdout=none;notify=all -o... John> so I don't get any mail from the cron demon at night. This way all John> status messages would get send through mail, which I could then peruse John> at my leasure. Has anyone else done something like this? I'm willing John> to take a stab at it if people think this would be a worth while John> endeavour. John> John }-- End of excerpt from Neal Becker -- +------------------------+------------------------------+ | sean_boyle@mentorg.com | Mentor Graphics Corporation | | uunet!mntgfx!sboyle | 8005 S.W. Boeckman Road | | | Wilsonville, OR 97070-7777 | | "Intrinsically lazy, therefore creative" | +------------------------+------------------------------+ From john@wpi.WPI.EDU Tue Apr 27 13:54:25 1993 Return-Path: Received: from bigboote.WPI.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25385; Tue, 27 Apr 93 13:54:25 PDT Received: from sekrit.WPI.EDU by bigboote.WPI.EDU (ALPHA-6.55/6.12) id QAA04966; Tue, 27 Apr 1993 16:54:22 -0400 From: John Stoffel Received: from localhost by sekrit.WPI.EDU (ALPHA-6.55/6.12) id QAA03873; Tue, 27 Apr 1993 16:54:23 -0400 Date: Tue, 27 Apr 1993 16:54:23 -0400 Message-Id: <199304272054.QAA03873@sekrit.WPI.EDU> To: rdist-dev@usc.edu Subject: Re: using rdist in a cron job I'd like to thank the following people for some hints and ideas on what I'm going to do instead of hacking the code. Anthony Datri (aad@lovecraft.siemens.com), Rich Salz (rsalz@osf.org), Neal Becker (neal@ctd.comsat.com) and Sean Boyle (sboyle@wv.mentorg.com). I'n now using: #!/bin/sh /usr/ucb/rdist -f /wpi/local/etc/artin.rdist -oyounger,ignlnks,remove,quiet -l notify=all 2> /tmp/messages$$ > /dev/null if [ -s /tmp/messages$$ ]; then /usr/ucb/mail -s "rdist messages" john < /tmp/messages$$ fi /bin/rm -f /tmp/messages$$ Which saves everything sent to stderr, but tosses everything else to /dev/null. Should make it much nicer. But I still think I should be able to tell rdist to send all output (be it stdout or stderr) to a certain place. Of course, what do you do when you have a problem in your command line? So the above method is better for catching that exception. Thanks again for all the replys. John From dla@se05.wg2.waii.com Fri May 7 10:17:27 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07165; Fri, 7 May 93 10:17:27 PDT Received: from outpost.wg.waii.com (via [198.3.192.2]) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27150; Fri, 7 May 93 13:17:14 -0400 Received: from airgun.wg.waii.com by outpost.wg.waii.com with SMTP id AA05895 (5.65c/IDA-1.4.4 for ); Fri, 7 May 1993 12:17:08 -0500 Received: from se01 (se01.wg2.waii.com) by airgun.wg.waii.com with SMTP id AA05144 (5.65c/IDA-1.4.4 for ); Fri, 7 May 1993 12:17:04 -0500 Received: from se05 (se05.wg2.waii.com) by se01 (4.1/SMI-4.1) id AA29009; Fri, 7 May 93 12:17:05 CDT Received: by se05 (4.1/SMI-4.1) id AA09922; Fri, 7 May 93 12:17:05 CDT Date: Fri, 7 May 93 12:17:05 CDT From: dla@se05.wg2.waii.com (Doug Acker) Message-Id: <9305071717.AA09922@se05> To: rdist-dev@usc.edu Subject: rdist on Solaris? Does anyone have patches to compile rdist on solaris 2.X? I figure I will ask first before I reinvent the wheel.... thanx in advance. Doug From mcooper@acamar.usc.edu Fri May 7 10:28:18 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07618; Fri, 7 May 93 10:28:18 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA26971; Fri, 7 May 93 10:28:13 PDT Sender: "Michael A. Cooper" Date: Fri, 7 May 93 10:28:12 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dla@se05.wg2.waii.com (Doug Acker) Cc: rdist-dev@usc.edu Subject: Re: rdist on Solaris? In-Reply-To: Your message of Fri, 7 May 93 12:17:05 CDT Message-Id: Content-Length: 68 Rdist 6.1beta.1 already compiles and runs under Solaris 2.1. mike From dpk@fid.morgan.com Fri May 7 12:38:13 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12871; Fri, 7 May 93 12:38:13 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41390>; Fri, 7 May 1993 15:37:55 -0400 Received: from rr5.acf (rr5-f0) by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA07800; Fri, 7 May 93 15:37:50 EDT Date: Fri, 7 May 1993 15:37:50 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305071937.AA07800@rs2.fid.morgan.com> To: rdist-dev@usc.edu Subject: bug in rdist.6.0.0 and rdist.6.1beta1 if you give rdist a long string of files, it is possible to overwrite the heap in debugmsg which uses a static buffer of 8K (BUFSIZ). This is particularly likely when it is handed a buffer built with getnlstr() which will build a buffer up to 16K. For the time being I have commented out the calls to debugmsg(..., ..., getnlstr()); in rdist.c near line 357. -Doug- From dpk@fid.morgan.com Fri May 7 14:59:22 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18250; Fri, 7 May 93 14:59:22 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41390>; Fri, 7 May 1993 17:59:07 -0400 Received: from foreign.acf by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA10848; Fri, 7 May 93 17:58:53 EDT Date: Fri, 7 May 1993 17:58:53 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305071758.ZM11315@foreign.fid.morgan.com> X-Mailer: Z-Mail (2.1b.1326 26jan93 OpenLook) To: rdist-dev@usc.edu Subject: looping bug in rdist 6.0.0 I don't have a lot on information on this one yet but here goes: We have been seeing a number of rdists go into a spinloop with the following system call trace: ... select (256, 0xf7fffc40, 0, 0, 0) = 1 read (3, "", 1024) = 0 select (256, 0xf7fffc40, 0, 0, 0) = 1 read (3, "", 1024) = 0 select (256, 0xf7fffc40, 0, 0, 0) = 1 read (3, "", 1024) = 0 select (256, 0xf7fffc40, 0, 0, 0) = 1 read (3, "", 1024) = 0 ... I have investigated some and found that there appears to be some problem in child.c. It appears that activechildren > 0 and needscan is false. It looks like if childscan was called, all would be well. I think something is not setting needscan when it should. I have not checked for this bug in 6.1beta1, but the code does not look too different. Thoughts Mike? -Doug- From dpk@fid.morgan.com Tue May 11 08:48:26 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11125; Tue, 11 May 93 08:48:26 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41386>; Tue, 11 May 1993 11:48:07 -0400 Received: by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA19210; Tue, 11 May 93 11:47:56 EDT Date: Tue, 11 May 1993 11:47:56 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305111547.AA19210@rs2.fid.morgan.com> To: rdist-dev@usc.edu Subject: TEST_SIGNAL I would like to suggest that instead of using TEST_SIGNAL (SIG_USR1), we instead use 0, as defined in POSIX to test that the process still exists (see section 3.3.2.2, last two sentences of first paragraph). "If sig is zero (the null signal), error checking is performed but no signal is actually sent. The null signal can be used to test the validity of pid." I believe that this behavior has been available since version 6, and is supported by all flavors of UNIX I know of. -Doug- From wls@astro.UMD.EDU Tue May 11 09:08:15 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12133; Tue, 11 May 93 09:08:15 PDT Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA29692; Tue, 11 May 1993 12:08:06 -0400 Date: Tue, 11 May 1993 12:08:06 -0400 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199305111608.AA29692@lynx.astro.umd.edu> To: dpk@fid.morgan.com Subject: Re: TEST_SIGNAL Cc: rdist-dev@usc.edu > "If sig is zero (the null signal), error checking is performed > but no signal is actually sent. The null signal can be used > to test the validity of pid." > > I believe that this behavior has been available since version 6, Not quite true. I can remember hacking it into 4.2 BSD where it was definitely not present by default. > and > is supported by all flavors of UNIX I know of. True as far as I know. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From mcooper@acamar.usc.edu Tue May 11 10:48:40 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15809; Tue, 11 May 93 10:48:40 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA02439; Tue, 11 May 93 10:48:33 PDT Sender: "Michael A. Cooper" Date: Tue, 11 May 93 10:48:31 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.morgan.com (Doug Kingston) Cc: rdist-dev@usc.edu Subject: Re: TEST_SIGNAL In-Reply-To: Your message of Tue, 11 May 1993 11:47:56 -0400 Message-Id: Content-Length: 145 How about if we make TEST_SIGNAL be 0 by default? That way, somebody with a system that doesn't support 0 can change it without problem? mike From dpk@fid.morgan.com Mon May 17 11:11:53 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23307; Mon, 17 May 93 11:11:53 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41394>; Mon, 17 May 1993 14:11:29 -0400 Received: from rr5.acf (rr5-f0) by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA03188; Mon, 17 May 93 14:11:18 EDT Date: Mon, 17 May 1993 14:11:18 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305171811.AA03188@rs2.fid.morgan.com> To: rdist-dev@usc.edu Subject: erroneous modes on new directories Cc: dff@fid.morgan.com when rdist makes a directory in order to make a place for a file it is distributing, it seems to make the directory world writable. I may also not get ownership correct if you distribute as root (I have not tested). Note that in the following example, the directory mode of 775 was not placed on the directories created by rdist in order to distribute the file foo. Cheers, -Doug- rr5 /u/dpk 548$ ls -alR a total 6 drwxrwxr-x 3 dpk 512 May 17 14:06 . drwxrwxr-x 34 dpk 4096 May 17 14:06 .. drwxrwxr-x 3 dpk 512 May 17 14:06 b a/b: total 3 drwxrwxr-x 3 dpk 512 May 17 14:06 . drwxrwxr-x 3 dpk 512 May 17 14:06 .. drwxrwxr-x 2 dpk 512 May 17 14:06 c a/b/c: total 2 drwxrwxr-x 2 dpk 512 May 17 14:06 . drwxrwxr-x 3 dpk 512 May 17 14:06 .. -rw-rw-r-- 1 dpk 0 May 17 14:06 foo rr5 /u/dpk 549$ rdist -c a/b/c/foo ns1 ns1: updating host ns1 ns1: a/b/c/foo: installing ns1: a: mkdir ns1: a/b: mkdir ns1: a/b/c: mkdir ns1: updating of ns1 finished rr5 /u/dpk 550$ rsh ns1 ls -alR a total 5 drwxrwsrwx 3 dpk 512 May 17 14:06 . drwxrwsr-x 15 dpk 2560 May 17 14:06 .. drwxrwsrwx 3 dpk 512 May 17 14:06 b a/b: total 3 drwxrwsrwx 3 dpk 512 May 17 14:06 . drwxrwsrwx 3 dpk 512 May 17 14:06 .. drwxrwsrwx 2 dpk 512 May 17 14:06 c a/b/c: total 2 drwxrwsrwx 2 dpk 512 May 17 14:06 . drwxrwsrwx 3 dpk 512 May 17 14:06 .. -rw-rw-r-- 1 dpk 0 May 17 14:06 foo rr5 /u/dpk 551$ ------- end of example -------- From mcooper@acamar.usc.edu Mon May 17 11:19:39 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23614; Mon, 17 May 93 11:19:39 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA20846; Mon, 17 May 93 11:19:33 PDT Sender: "Michael A. Cooper" Date: Mon, 17 May 93 11:19:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.morgan.com (Doug Kingston) Cc: rdist-dev@usc.edu, dff@fid.morgan.com Subject: Re: erroneous modes on new directories In-Reply-To: Your message of Mon, 17 May 1993 14:11:18 -0400 Message-Id: Content-Length: 194 That should be taken care of by your umask. At least, it does for me. I could explicitly set the modes of these new directories. Anybody want to vote on what that mode should be? 755? mike From dpk@fid.morgan.com Mon May 17 11:37:16 1993 Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24353; Mon, 17 May 93 11:37:16 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41393>; Mon, 17 May 1993 14:36:52 -0400 Received: from foreign.acf by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA03429; Mon, 17 May 93 14:36:44 EDT Date: Mon, 17 May 1993 14:36:44 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305171436.ZM29431@foreign.fid.morgan.com> In-Reply-To: "Re: erroneous modes on new directories" (May 17, 14:19) References: X-Mailer: Z-Mail (2.1.4 02apr93 OpenLook) To: mcooper@usc.edu, dpk@fid.morgan.com (Doug Kingston) Subject: Re: erroneous modes on new directories Cc: rdist-dev@usc.edu, dff@fid.morgan.com What's wrong the the original modes of the "model" directory? I assume from your suggestion that you do not have that information available to the server rdist process? -Doug- From mcooper@acamar.usc.edu Mon May 17 18:00:55 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09393; Mon, 17 May 93 18:00:55 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA22421; Mon, 17 May 93 18:00:49 PDT Sender: "Michael A. Cooper" Date: Mon, 17 May 93 18:00:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.morgan.com (Doug Kingston) Cc: dpk@fid.morgan.com (Doug Kingston), rdist-dev@usc.edu, dff@fid.morgan.com Subject: Re: erroneous modes on new directories In-Reply-To: Your message of Mon, 17 May 1993 14:36:44 -0400 Message-Id: Content-Length: 334 > What's wrong the the original modes of the "model" directory? > > I assume from your suggestion that you do not have that information > available to the server rdist process? > > -Doug- > The info is available in some cases and is used in those cases. This may be a problem with a -c option and using an actual distfile. mike From wambold@magnus.acs.ohio-state.edu Thu May 20 12:36:49 1993 Return-Path: Received: from magnusug.magnus.acs.ohio-state.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23652; Thu, 20 May 93 12:36:49 PDT Received: by magnusug.magnus.acs.ohio-state.edu (5.65/3.910213) id AA01144; Thu, 20 May 93 15:15:36 -0400 Date: Thu, 20 May 93 15:15:36 -0400 From: Sandra Wambold Message-Id: <9305201915.AA01144@magnusug.magnus.acs.ohio-state.edu> To: rdist-dev@usc.edu Subject: Library problem when compiling on HP-UX 9.01 When I went to compile rdist (both 6.0.0 and 6.1beta.1) on a HP 9000/700 series machine running HP-UX 9.01, I got the following error for both `cc' and `gcc 2.3.3': cc -o rdistd rdistd.o server.o filesys.o filesys-os.o common.o message.o setargs.o strcasecmp.o regex.o -lPW /bin/ld: Duplicate symbol "fatal", files message.o and /lib/libPW.a(fatal.o) /bin/ld: Unsatisfied symbols: Error (data) /bin/ld: Found 1 duplicate symbol(s) By reading the FAQ for comp.sys.hp, I found this: > >6.2) Where is regcmp on HP-UX? > >RTFM - from man regcmp: > > regcmp and regex are kept in /lib/libPW.a, and are linked by using the > -lc and -lPW options to the ld or cc command. See WARNINGS below. >... > > WARNINGS > regcmp and regex are kept in /lib/libPW.a. Unfortunately, > /lib/libPW.a also contains some functions that have the same names as > functions contained in the default C library, /lib/libc.a. To prevent > unexpected results due to these name conflicts, always search libc > before searching libPW. This is done with the ld (or cc) command line > option sequence -lc -lPW which satisifies all standard C functions > from libc then searches libPW for the regcmp and regex functions > (there is also an implied -lc following the explicit -lPW to satisfy > any additional C functions required by regcmp and regex). > > User programs that use regcmp might run out of memory if regcmp is > called iteratively without freeing vectors that are no longer > required. > >[thanks to Andre Srinivasan, ] When I added the `-lc' before the `-lPW' the program compiled nicely. -Sandy From neal@ctd.comsat.com Thu May 20 12:47:01 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24212; Thu, 20 May 93 12:47:01 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nwGZg-0003TdC; Thu, 20 May 93 15:46 EDT Message-Id: Date: Thu, 20 May 93 15:46 EDT From: neal@ctd.comsat.com (Neal Becker) To: Sandra Wambold Cc: rdist-dev@usc.edu Subject: Library problem when compiling on HP-UX 9.01 In-Reply-To: <9305201915.AA01144@magnusug.magnus.acs.ohio-state.edu> References: <9305201915.AA01144@magnusug.magnus.acs.ohio-state.edu> Don't use -lPW. Ever. :-) Seriously, try this: ---------------------------- diff -c config/mf.hpux~ config/mf.hpux *** config/mf.hpux~ Sat Feb 20 19:46:44 1993 --- config/mf.hpux Mon Mar 29 16:11:29 1993 *************** *** 47,50 **** # # System libraries that we need to load. # ! LIB_SYS = -lPW --- 47,50 ---- # # System libraries that we need to load. # ! LIB_SYS = -------------------------------------------- >>>>> On Thu, 20 May 93 15:15:36 -0400, Sandra Wambold said: Sandra> When I went to compile rdist (both 6.0.0 and 6.1beta.1) on a HP Sandra> 9000/700 series machine running HP-UX 9.01, I got the following error Sandra> for both `cc' and `gcc 2.3.3': Sandra> cc -o rdistd rdistd.o server.o filesys.o filesys-os.o common.o message.o setargs.o strcasecmp.o regex.o -lPW Sandra> /bin/ld: Duplicate symbol "fatal", files message.o and /lib/libPW.a(fatal.o) Sandra> /bin/ld: Unsatisfied symbols: Sandra> Error (data) Sandra> /bin/ld: Found 1 duplicate symbol(s) Sandra> By reading the FAQ for comp.sys.hp, I found this: > >6.2) Where is regcmp on HP-UX? > >RTFM - from man regcmp: > > regcmp and regex are kept in /lib/libPW.a, and are linked by using the > -lc and -lPW options to the ld or cc command. See WARNINGS below. >... > > WARNINGS > regcmp and regex are kept in /lib/libPW.a. Unfortunately, > /lib/libPW.a also contains some functions that have the same names as > functions contained in the default C library, /lib/libc.a. To prevent > unexpected results due to these name conflicts, always search libc > before searching libPW. This is done with the ld (or cc) command line > option sequence -lc -lPW which satisifies all standard C functions > from libc then searches libPW for the regcmp and regex functions > (there is also an implied -lc following the explicit -lPW to satisfy > any additional C functions required by regcmp and regex). > > User programs that use regcmp might run out of memory if regcmp is > called iteratively without freeing vectors that are no longer > required. > >[thanks to Andre Srinivasan, ] Sandra> When I added the `-lc' before the `-lPW' the program compiled nicely. Sandra> -Sandy From neal@ctd.comsat.com Thu May 20 12:51:19 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24619; Thu, 20 May 93 12:51:19 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #7) id m0nwGds-0003TdC; Thu, 20 May 93 15:51 EDT Message-Id: Date: Thu, 20 May 93 15:51 EDT From: neal@ctd.comsat.com (Neal Becker) To: neal@ctd.comsat.com (Neal Becker) Cc: Sandra Wambold , rdist-dev@usc.edu Subject: Library problem when compiling on HP-UX 9.01 In-Reply-To: References: <9305201915.AA01144@magnusug.magnus.acs.ohio-state.edu> Sorry, the last patch was missing this. You need to also add this to config/mf.hpux: ------------------------------------- MISSINGOBJS = $(O)strcasecmp.o $(O)regex.o ------------------------------------- From john@wpi.WPI.EDU Fri May 28 07:31:34 1993 Return-Path: Received: from bigboote.WPI.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02940; Fri, 28 May 93 07:31:34 PDT Received: from sekrit.WPI.EDU (john@sekrit.WPI.EDU [130.215.24.6]) by bigboote.WPI.EDU (ALPHA-6.61/6.28) id KAA24793; Fri, 28 May 1993 10:31:32 -0400 From: John Stoffel Received: from localhost by sekrit.WPI.EDU (ALPHA-6.61/6.12) id KAA12044; Fri, 28 May 1993 10:31:31 -0400 Date: Fri, 28 May 1993 10:31:31 -0400 Message-Id: <199305281431.KAA12044@sekrit.WPI.EDU> To: rdist-dev@usc.edu Subject: Debugging rdistd Anyone have any hints on how to run rdistd under a debugger? I want to check what some of the code in fchog() in server.c is doing when I run it. Do I have to re-compile rdist to execute something like 'gdb rdistd' on the remote host? Thanks! John From rouilj@cs.umb.edu Fri May 28 08:45:17 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05731; Fri, 28 May 93 08:45:17 PDT Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA19941 (5.65c/IDA-1.4.4 for ); Fri, 28 May 1993 11:45:11 -0400 Message-Id: <199305281545.AA19941@cs.umb.edu> To: John Stoffel Cc: rdist-dev@usc.edu Subject: Re: Debugging rdistd In-Reply-To: Your message of "Fri, 28 May 1993 10:31:31 EDT." <199305281431.KAA12044@sekrit.WPI.EDU> Date: Fri, 28 May 1993 11:45:10 -0400 From: "John P. Rouillard" In message <199305281431.KAA12044@sekrit.WPI.EDU>, John Stoffel writes: > > Anyone have any hints on how to run rdistd under a debugger? I want > to check what some of the code in fchog() in server.c is doing when I > run it. Depends on what type os system you are on. Some systems SVR4, Suns allow you to debug an already running process using its pid. If I am doing this type of debugging, I will put an infinite loop of the sort: int a=0; for (;;) if (a == 234) break; Then I attach to the process with gdb, set a to 234, (make sure you have optimization turned off when you compile otherwise a will be optimized away), and debug. > Do I have to re-compile rdist to execute something like 'gdb > rdistd' on the remote host? Thanks! Well rdistd could just be a script that does the 'gdb rdistd.real', no recompile necessary. However, I doubt this would work since you have no I/O channel to gdb, and rdist would get indegestion seeing the (gdb) prompt. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Siemens-Nixdorf USA rouilj@sni-usa.com Burlington, MA, (617) 273-2687 x-3498 =============================================================================== My employers don't acknowledge my existence much less my opinions. From mcooper@acamar.usc.edu Fri May 28 10:46:22 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10316; Fri, 28 May 93 10:46:22 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA06960; Fri, 28 May 93 10:46:10 PDT Sender: "Michael A. Cooper" Date: Fri, 28 May 93 10:46:09 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: John Stoffel Cc: rdist-dev@usc.edu Subject: Re: Debugging rdistd In-Reply-To: Your message of Fri, 28 May 1993 10:31:31 -0400 Message-Id: Content-Length: 239 I usually put a "sleep(30)" in rdistd, usually at the top of the main command loop. I run rdist and then use a debugger that can attach to a running process (using ptrace). This is supported with dbx under SunOS 4.1.x and others. mike From dbeusee@us.oracle.com Tue Jun 1 23:24:47 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17375; Tue, 1 Jun 93 23:24:47 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA14040; Tue, 1 Jun 93 23:24:41 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29625; Tue, 1 Jun 93 23:18:48 PDT Message-Id: <9306020618.AA29625@dbeusee.us.oracle.com> Date: Tue, 1 Jun 93 23:18:48 PDT From: Don Beusee To: dpk@fid.morgan.com Subject: Re: TEST_SIGNAL Cc: rdist-dev@usc.edu I would suggest leaving TEST_SIGNAL set to zero in case there is a flavor of unix that acts funny. From dpk@fid.morgan.com Tue May 11 09:15:39 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20846; Tue, 11 May 93 09:15:38 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA05446; Tue, 11 May 93 09:21:33 PDT Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11125; Tue, 11 May 93 08:48:26 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41386>; Tue, 11 May 1993 11:48:07 -0400 Received: by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA19210; Tue, 11 May 93 11:47:56 EDT Date: Tue, 11 May 1993 11:47:56 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305111547.AA19210@rs2.fid.morgan.com> To: rdist-dev@usc.edu Subject: TEST_SIGNAL Status: R I would like to suggest that instead of using TEST_SIGNAL (SIG_USR1), we instead use 0, as defined in POSIX to test that the process still exists (see section 3.3.2.2, last two sentences of first paragraph). "If sig is zero (the null signal), error checking is performed but no signal is actually sent. The null signal can be used to test the validity of pid." I believe that this behavior has been available since version 6, and is supported by all flavors of UNIX I know of. -Doug- From dbeusee@us.oracle.com Wed Jun 2 11:25:38 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09150; Wed, 2 Jun 93 11:25:38 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA09212; Wed, 2 Jun 93 11:25:28 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01491; Wed, 2 Jun 93 11:19:37 PDT Message-Id: <9306021819.AA01491@dbeusee.us.oracle.com> Date: Wed, 2 Jun 93 11:19:37 PDT From: Don Beusee To: dpk@fid.morgan.com, mcooper@usc.edu Subject: Re: erroneous modes on new directories Cc: dff@fid.morgan.com, rdist-dev@usc.edu I think the umask should be used. That gives the user total control over it. From mcooper@acamar.usc.edu Mon May 17 11:28:53 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01512; Mon, 17 May 93 11:28:52 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA05706; Mon, 17 May 93 11:34:42 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23614; Mon, 17 May 93 11:19:39 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA20846; Mon, 17 May 93 11:19:33 PDT Sender: "Michael A. Cooper" Date: Mon, 17 May 93 11:19:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.morgan.com (Doug Kingston) Cc: rdist-dev@usc.edu, dff@fid.morgan.com Subject: Re: erroneous modes on new directories In-Reply-To: Your message of Mon, 17 May 1993 14:11:18 -0400 Message-Id: Content-Length: 194 Status: R That should be taken care of by your umask. At least, it does for me. I could explicitly set the modes of these new directories. Anybody want to vote on what that mode should be? 755? mike From dbeusee@us.oracle.com Wed Jun 2 11:28:43 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09235; Wed, 2 Jun 93 11:28:43 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA09576; Wed, 2 Jun 93 11:28:33 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01503; Wed, 2 Jun 93 11:22:42 PDT Message-Id: <9306021822.AA01503@dbeusee.us.oracle.com> Date: Wed, 2 Jun 93 11:22:42 PDT From: Don Beusee To: dpk@fid.morgan.com, mcooper@usc.edu Subject: Re: erroneous modes on new directories Cc: dff@fid.morgan.com, rdist-dev@usc.edu What if you specify a different target? The source dir would not mean anything. I think the umask is perfect for this. The source modes are and should be used when rdisting a directory. From dpk@fid.morgan.com Mon May 17 11:44:43 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01556; Mon, 17 May 93 11:44:42 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA07486; Mon, 17 May 93 11:50:32 PDT Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24353; Mon, 17 May 93 11:37:16 PDT Received: from rs2.fid.morgan.com ([138.20.2.27]) by gateway.morgan.com with SMTP id <41393>; Mon, 17 May 1993 14:36:52 -0400 Received: from foreign.acf by rs2.fid.morgan.com (4.1/MS/FID-1.0) id AA03429; Mon, 17 May 93 14:36:44 EDT Date: Mon, 17 May 1993 14:36:44 -0400 From: dpk@fid.morgan.com (Doug Kingston) Message-Id: <9305171436.ZM29431@foreign.fid.morgan.com> In-Reply-To: "Re: erroneous modes on new directories" (May 17, 14:19) References: X-Mailer: Z-Mail (2.1.4 02apr93 OpenLook) To: mcooper@usc.edu, dpk@fid.morgan.com (Doug Kingston) Subject: Re: erroneous modes on new directories Cc: rdist-dev@usc.edu, dff@fid.morgan.com Status: R What's wrong the the original modes of the "model" directory? I assume from your suggestion that you do not have that information available to the server rdist process? -Doug- From dbeusee@us.oracle.com Wed Jun 2 11:47:53 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10100; Wed, 2 Jun 93 11:47:53 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11841; Wed, 2 Jun 93 11:47:43 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01582; Wed, 2 Jun 93 11:41:51 PDT Message-Id: <9306021841.AA01582@dbeusee.us.oracle.com> Date: Wed, 2 Jun 93 11:41:51 PDT From: Don Beusee To: dpk@fid.morgan.com, mcooper@usc.edu Subject: Re: erroneous modes on new directories Cc: dff@fid.morgan.com, rdist-dev@usc.edu I think it has to do with rdisting a single file - should do the same thing from a distfile or -c I would think. From mcooper@acamar.usc.edu Mon May 17 18:09:23 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA01866; Mon, 17 May 93 18:09:22 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA15181; Mon, 17 May 93 18:15:13 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09393; Mon, 17 May 93 18:00:55 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA22421; Mon, 17 May 93 18:00:49 PDT Sender: "Michael A. Cooper" Date: Mon, 17 May 93 18:00:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dpk@fid.morgan.com (Doug Kingston) Cc: dpk@fid.morgan.com (Doug Kingston), rdist-dev@usc.edu, dff@fid.morgan.com Subject: Re: erroneous modes on new directories In-Reply-To: Your message of Mon, 17 May 1993 14:36:44 -0400 Message-Id: Content-Length: 334 Status: R > What's wrong the the original modes of the "model" directory? > > I assume from your suggestion that you do not have that information > available to the server rdist process? > > -Doug- > The info is available in some cases and is used in those cases. This may be a problem with a -c option and using an actual distfile. mike From hirai@cc.swarthmore.edu Thu Jun 3 07:39:21 1993 Return-Path: Received: from oak.cc.swarthmore.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18631; Thu, 3 Jun 93 07:39:21 PDT Received: by oak.cc.swarthmore.edu (sendmail 5.57/oak04-22-93) id AA13647; Thu, 3 Jun 93 10:39:19 -0400 Received: by gingko.cc.swarthmore.edu (sendmail 5.57/client04-17-92) id AA12541; Thu, 3 Jun 93 10:39:18 -0400 Message-Id: <9306031439.AA12541@gingko.cc.swarthmore.edu> From: hirai@cc.swarthmore.edu (Eiji Hirai) Date: Thu, 3 Jun 1993 10:39:18 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: rdist temp files I'm using rdist-6.1b1 on Ultrix 4.2A. When I rdist, I sometimes get the following error message. : local error: /usr/gnu/lib/gcc-lib/mips-dec-ultrix/2.4.2/include/rdista12393: lstat failed: No such file or directory I assume that "rdista12393" is a temporary file created by rdist. Is this a timing problem of one child rdist trying to distribute a directory and trying to distribute a temporary file created by another child rdist? From mcooper@acamar.usc.edu Thu Jun 3 10:51:29 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26861; Thu, 3 Jun 93 10:51:29 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA05202; Thu, 3 Jun 93 10:51:17 PDT Sender: "Michael A. Cooper" Date: Thu, 3 Jun 93 10:51:16 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: hirai@cc.swarthmore.edu (Eiji Hirai) Cc: rdist-dev@usc.edu Subject: Re: rdist temp files In-Reply-To: Your message of Thu, 3 Jun 1993 10:39:18 -0400 Message-Id: Content-Length: 106 It sure sounds like that's the case. Are you running multiple updates to the same host/directory? mike From hirai@cc.swarthmore.edu Thu Jun 3 11:18:19 1993 Return-Path: Received: from oak.cc.swarthmore.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28198; Thu, 3 Jun 93 11:18:19 PDT Received: by oak.cc.swarthmore.edu (sendmail 5.57/oak04-22-93) id AA22564; Thu, 3 Jun 93 14:18:17 -0400 Received: by gingko.cc.swarthmore.edu (sendmail 5.57/client04-17-92) id AA13182; Thu, 3 Jun 93 14:18:16 -0400 Message-Id: <9306031818.AA13182@gingko.cc.swarthmore.edu> From: hirai@cc.swarthmore.edu (Eiji Hirai) Date: Thu, 3 Jun 1993 14:18:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: Re: rdist temp files I guess what I was asking was, should I use "rdist -M 1" to avoid this temp file problem? This seems kind of sad since one the biggest wins for rdist is being able to do "rdist -M 4". From mcooper@acamar.usc.edu Thu Jun 3 11:26:26 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28439; Thu, 3 Jun 93 11:26:26 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA05329; Thu, 3 Jun 93 11:26:15 PDT Sender: "Michael A. Cooper" Date: Thu, 3 Jun 93 11:26:15 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: hirai@cc.swarthmore.edu (Eiji Hirai) Cc: rdist-dev@usc.edu Subject: Re: rdist temp files In-Reply-To: Your message of Thu, 3 Jun 1993 14:18:16 -0400 Message-Id: Content-Length: 222 There shouldn't be any case where running multiple client updates at once causes that problem, unless you have some weird setup where the you are updating the same filesystem remotely mounted on your rdist clients. mike From dbeusee@us.oracle.com Thu Jun 3 12:16:35 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00656; Thu, 3 Jun 93 12:16:35 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA12051; Thu, 3 Jun 93 12:16:28 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06261; Thu, 3 Jun 93 12:10:43 PDT Message-Id: <9306031910.AA06261@dbeusee.us.oracle.com> Date: Thu, 3 Jun 93 12:10:43 PDT From: Don Beusee To: hirai@cc.swarthmore.edu, mcooper@usc.edu Subject: Re: rdist temp files Cc: rdist-dev@usc.edu I sent a note about a bug with forking multiple children (some hosts not getting updated). I verified that using -F works correctly. Did anybody look at it? From mcooper@acamar.usc.edu Thu Jun 3 11:03:23 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA05885; Thu, 3 Jun 93 11:03:21 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA04717; Thu, 3 Jun 93 11:08:55 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26861; Thu, 3 Jun 93 10:51:29 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA05202; Thu, 3 Jun 93 10:51:17 PDT Sender: "Michael A. Cooper" Date: Thu, 3 Jun 93 10:51:16 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: hirai@cc.swarthmore.edu (Eiji Hirai) Cc: rdist-dev@usc.edu Subject: Re: rdist temp files In-Reply-To: Your message of Thu, 3 Jun 1993 10:39:18 -0400 Message-Id: Content-Length: 106 Status: R It sure sounds like that's the case. Are you running multiple updates to the same host/directory? mike From dbeusee@us.oracle.com Thu Jun 3 12:22:35 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00856; Thu, 3 Jun 93 12:22:35 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA12766; Thu, 3 Jun 93 12:22:32 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06304; Thu, 3 Jun 93 12:16:47 PDT Message-Id: <9306031916.AA06304@dbeusee.us.oracle.com> Date: Thu, 3 Jun 93 12:16:47 PDT From: Don Beusee To: hirai@cc.swarthmore.edu, rdist-dev@usc.edu Subject: Re: rdist temp files Yes, but use -F instead of -M 1, since -F disables a lot of unneccessary code making serial updates more effecient then they would be with -M 1. There are 2 problems. The one you reported with the temp files and the one I reported with it not updating a few machines in a big list. I sent a note out a month ago about that. From hirai@cc.swarthmore.edu Thu Jun 3 11:31:38 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06041; Thu, 3 Jun 93 11:31:35 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA07849; Thu, 3 Jun 93 11:37:16 PDT Received: from oak.cc.swarthmore.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28198; Thu, 3 Jun 93 11:18:19 PDT Received: by oak.cc.swarthmore.edu (sendmail 5.57/oak04-22-93) id AA22564; Thu, 3 Jun 93 14:18:17 -0400 Received: by gingko.cc.swarthmore.edu (sendmail 5.57/client04-17-92) id AA13182; Thu, 3 Jun 93 14:18:16 -0400 Message-Id: <9306031818.AA13182@gingko.cc.swarthmore.edu> From: hirai@cc.swarthmore.edu (Eiji Hirai) Date: Thu, 3 Jun 1993 14:18:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: Re: rdist temp files Status: R I guess what I was asking was, should I use "rdist -M 1" to avoid this temp file problem? This seems kind of sad since one the biggest wins for rdist is being able to do "rdist -M 4". From mcooper@acamar.usc.edu Thu Jun 3 12:34:15 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01260; Thu, 3 Jun 93 12:34:15 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA05544; Thu, 3 Jun 93 12:33:54 PDT Sender: "Michael A. Cooper" Date: Thu, 3 Jun 93 12:33:54 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: hirai@cc.swarthmore.edu, rdist-dev@usc.edu Subject: Re: rdist temp files In-Reply-To: Your message of Thu, 3 Jun 93 12:10:43 PDT Message-Id: Content-Length: 100 I have not had time to work on rdist for almost 2 months now. So, no I haven't looked at it. mike From neal@ctd.comsat.com Tue Jun 29 07:09:09 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10500; Tue, 29 Jun 93 07:09:09 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oAgMo-0003UnC; Tue, 29 Jun 93 10:09 EDT Message-Id: Date: Tue, 29 Jun 93 10:09 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist@usc.edu Subject: Bug in symlink install On some systems (sysv-ish) you need to rename a running executable to do install. Patches were added to fix this some time ago. I just found that a similar patch is needed where a symlink is installed, replacing an existing executable file that is executing. From steve@cs.uow.edu.au Tue Jun 29 19:09:22 1993 Return-Path: Received: from wraith.cs.uow.edu.au by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11505; Tue, 29 Jun 93 19:09:22 PDT Received: by wraith.cs.uow.edu.au (5.65c/IDA-1.4.4); id AA21203; Wed, 30 Jun 1993 12:08:57 +1000 (from steve@cs.uow.edu.au for rdist-dev@usc.edu) From: Stephen Cliffe Message-Id: <199306300208.AA21203@wraith.cs.uow.edu.au> Subject: Error messages from rdist To: rdist-dev@usc.edu Date: Wed, 30 Jun 1993 12:08:57 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1034 We've been running 6.1beta patchlevel 1 for a while now and I keep seeing things like this: root@falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4: mkdir root@falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/xyagi: installing falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4/rdista16285: removed falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/xyagi: installing root@falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4/rdista16285: utimes failed: No such file or directory falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/mn_help: installing root@falin.cs.uow.edu.au: falin: REMOTE ERROR: /shr/packages/mimenice/bin/sun4/rdista16285 -> /shr/packages/mimenice/bin/sun4/xyagi: rename failed: No such file or directory root@falin.cs.uow.edu.au: LOCAL ERROR: update: unexpected response '' root@falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/Ngbp: installing root@falin.cs.uow.edu.au: N root@falin.cs.uow.edu.au: LOCAL ERROR: update: unexpected response '' What does it all mean? Steve. From dbeusee@us.oracle.com Tue Jun 29 20:49:41 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17265; Tue, 29 Jun 93 20:49:41 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA25897; Tue, 29 Jun 93 20:48:52 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28836; Tue, 29 Jun 93 20:43:23 PDT Message-Id: <9306300343.AA28836@dbeusee.us.oracle.com> Date: Tue, 29 Jun 93 20:43:23 PDT From: Don Beusee To: rdist-dev@usc.edu, steve@cs.uow.edu.au Subject: Re: Error messages from rdist One thing you need is my patches for 6.1.b1. You can find them in rdist-dev.archive file in /pub/rdist on usc.edu. These are the messages you want from that file (this is a unix mail file): Msg# Subject ---- ---------------------------------------------------------------------- 262 Jumbo destdir patch for 6.1.b1 (replaces previous b1 patches) 264 rdist patch to fix jumbo destdir patch core dump 265 remfilename() patch With these patches in place, rdist should not be confused about where the files are on the remote system. Let me know if the patches fix some of these problems or not. Mike, when is the next patch level going to be released? Just curious. I am still using -F option because rdist gets lost without it (some hosts (randomly selected) don't get updated). The next patch level should address this bug (I will work on it soon and see if I can get a patch out for it). Regards, Don. From steve@cs.uow.edu.au Tue Jun 29 19:26:07 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28611; Tue, 29 Jun 93 19:25:32 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA19701; Tue, 29 Jun 93 19:30:54 PDT Received: from wraith.cs.uow.edu.au by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11505; Tue, 29 Jun 93 19:09:22 PDT Received: by wraith.cs.uow.edu.au (5.65c/IDA-1.4.4); id AA21203; Wed, 30 Jun 1993 12:08:57 +1000 (from steve@cs.uow.edu.au for rdist-dev@usc.edu) From: Stephen Cliffe Message-Id: <199306300208.AA21203@wraith.cs.uow.edu.au> Subject: Error messages from rdist To: rdist-dev@usc.edu Date: Wed, 30 Jun 1993 12:08:57 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1034 Status: R We've been running 6.1beta patchlevel 1 for a while now and I keep seeing things like this: root@falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4: mkdir root@falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/xyagi: installing falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4/rdista16285: removed falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/xyagi: installing root@falin.cs.uow.edu.au: falin: /shr/packages/mimenice/bin/sun4/rdista16285: utimes failed: No such file or directory falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/mn_help: installing root@falin.cs.uow.edu.au: falin: REMOTE ERROR: /shr/packages/mimenice/bin/sun4/rdista16285 -> /shr/packages/mimenice/bin/sun4/xyagi: rename failed: No such file or directory root@falin.cs.uow.edu.au: LOCAL ERROR: update: unexpected response '' root@falin.cs.uow.edu.au: /shr/packages/mimenice/bin/sun4/Ngbp: installing root@falin.cs.uow.edu.au: N root@falin.cs.uow.edu.au: LOCAL ERROR: update: unexpected response '' What does it all mean? Steve. From mcooper@acamar.usc.edu Wed Jun 30 11:06:31 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21233; Wed, 30 Jun 93 11:06:31 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA23625; Wed, 30 Jun 93 11:06:16 PDT Sender: "Michael A. Cooper" Date: Wed, 30 Jun 93 11:06:16 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu, steve@cs.uow.edu.au Subject: Re: Error messages from rdist In-Reply-To: Your message of Tue, 29 Jun 93 20:43:23 PDT Message-Id: Content-Length: 92 I'm still swamped with other tasks and haven't had time to "finish" the beta of 6.1. mike From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Thu Jul 8 17:40:19 1993 Return-Path: Received: from relay2.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11447; Thu, 8 Jul 93 17:40:19 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23334; Thu, 8 Jul 93 20:39:09 -0400 Received: from meaddata.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 203735.5779; Thu, 8 Jul 1993 20:37:35 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA04911; Thu, 8 Jul 93 20:13:13 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA28659; Thu, 8 Jul 93 20:13:09 EDT Date: Thu, 8 Jul 93 20:13:09 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9307090013.AA28659@weasel.meaddata.com> To: rdist-dev@usc.edu Subject: question on setreuid() Please forgive what may be a bit of a newbie question. I see, based on the install option and the following code excerpt in rdist's main()... if (dosetreuid(0, userid) != 0) exit(1); that rdist expects to be setuid-root, though this is not the case for rdistd. It seems to be a win for security that rdistd gets no greater authority than is granted via rcmd(). Why is it useful for rdist to have greater authority than whomever happens to be running it at the time? From dbeusee@us.oracle.com Thu Jul 8 19:41:36 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15292; Thu, 8 Jul 93 19:41:36 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA20483; Thu, 8 Jul 93 19:41:32 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21415; Thu, 8 Jul 93 19:36:12 PDT Message-Id: <9307090236.AA21415@dbeusee.us.oracle.com> Date: Thu, 8 Jul 93 19:36:12 PDT From: Don Beusee To: rdist-dev@usc.edu, todd@meaddata.com Subject: Re: question on setreuid() rcmd() is only allowed when euid=0, since rcmd() is a priviledged operation. From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Thu Jul 8 17:51:51 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21199; Thu, 8 Jul 93 17:51:50 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA12599; Thu, 8 Jul 93 17:57:07 PDT Received: from relay2.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11447; Thu, 8 Jul 93 17:40:19 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23334; Thu, 8 Jul 93 20:39:09 -0400 Received: from meaddata.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 203735.5779; Thu, 8 Jul 1993 20:37:35 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA04911; Thu, 8 Jul 93 20:13:13 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA28659; Thu, 8 Jul 93 20:13:09 EDT Date: Thu, 8 Jul 93 20:13:09 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9307090013.AA28659@weasel.meaddata.com> To: rdist-dev@usc.edu Subject: question on setreuid() Status: R Please forgive what may be a bit of a newbie question. I see, based on the install option and the following code excerpt in rdist's main()... if (dosetreuid(0, userid) != 0) exit(1); that rdist expects to be setuid-root, though this is not the case for rdistd. It seems to be a win for security that rdistd gets no greater authority than is granted via rcmd(). Why is it useful for rdist to have greater authority than whomever happens to be running it at the time? From raeburn@cambridge.cygnus.com Thu Jul 8 20:32:28 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16877; Thu, 8 Jul 93 20:32:28 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21734; Thu, 8 Jul 93 23:31:07 -0400 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA13747; Thu, 8 Jul 93 20:31:02 PDT Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA24053; Thu, 8 Jul 93 23:30:34 EDT Message-Id: <9307090330.AA24053@tweedledumb.cygnus.com> To: Don Beusee Cc: rdist-dev@usc.edu, todd@meaddata.com Subject: Re: question on setreuid() In-Reply-To: Your message of "Thu, 08 Jul 93 19:36:12 PDT." <9307090236.AA21415@dbeusee.us.oracle.com> Date: Thu, 08 Jul 93 23:30:21 -0400 From: raeburn@cambridge.cygnus.com > rcmd() is only allowed when euid=0, since rcmd() is a priviledged operation. Is there anything else that requires root privs? I.e., if rdist is fixed to use Kerberos authentication, is there any other reason for it to be setuid? From yeoak@iscs.nus.sg Fri Jul 9 03:23:44 1993 Return-Path: Received: from nuscc.nus.sg by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29864; Fri, 9 Jul 93 03:23:44 PDT Received: from sun.iscs.nus.sg by nuscc.nus.sg (5.65/1.34) id AA25729; Fri, 9 Jul 93 18:19:04 +0800 Received: from elc1s.iscs.nus.sg by sun.iscs.nus.sg with SMTP id AA22733 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 18:18:34 +0800 Received: by elc1s.iscs.nus.sg (4.1/SMI-4.1) id AA15334; Fri, 9 Jul 93 18:17:14 SST From: yeoak@iscs.nus.sg (Yeo Ann Kian) Message-Id: <9307091017.AA15334@elc1s.iscs.nus.sg> Subject: rdist fails at "special" command when running on irix4 To: rdist-dev@usc.edu Date: Fri, 9 Jul 93 18:17:13 WST Cc: yeoak@elc1s.iscs.nus.sg (Yeo Ann Kian) X-Mailer: ELM [version 2.3 PL11] I tried to rdist from "idg4k1s" -> "idg4k2s" to install a file "t.sh" and execute "t.sh" when it is installed. Both "idg4k[12]s" run IriX4.0.5F. rdist complainted with "REMOTE ERROR". The line printed before "REMOTE ERROR" doesn't look right to me. Any idea? -------------------------------------------------------------------------- > rdist -f t.cf idg4k2s: updating host idg4k2s idg4k2s: /home/root/idg/t.sh: updating idg4k2s: special "/home/root/idg/t.sh" idg4k2s: k1s.iscs.nus.sg : is not an identifier idg4k2s: REMOTE ERROR: shell returned 256 idg4k2s: updating of idg4k2s finished >rdist -V Version 6.1beta.1 - Protocol Version 6, Release 6.1beta, Patch level 1 >cat t.cf # # File: t.cf HOSTS = ( idg4k2s ) FILES = ( /home/root/idg/t.sh ) ${FILES} -> ${HOSTS} install ; special "/home/root/idg/t.sh" ; >cat t.sh #!/bin/sh /bin/touch /tmp/ttt -- Ann-Kian Yeo Internet: yeoak@iscs.nus.sg 772-2780 Dept. of Information Systems and Computer Science (DISCS), NUS, Singapore From dbeusee@us.oracle.com Fri Jul 9 07:45:28 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07810; Fri, 9 Jul 93 07:45:28 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA08930; Fri, 9 Jul 93 07:45:15 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22971; Fri, 9 Jul 93 07:39:54 PDT Message-Id: <9307091439.AA22971@dbeusee.us.oracle.com> Date: Fri, 9 Jul 93 07:39:54 PDT From: Don Beusee To: raeburn@cambridge.cygnus.com Subject: Re: question on setreuid() Cc: rdist-dev@usc.edu, todd@meaddata.com No. You will notice that rdistd is NOT set-uid. The only reason rdist is set-uid is because it uses rcmd()... From raeburn@cambridge.cygnus.com Thu Jul 8 20:27:10 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21492; Thu, 8 Jul 93 20:27:09 PDT Received: from relay1.UU.NET by gatekeeper.oracle.com (5.59.11/37.7) id AA23781; Thu, 8 Jul 93 20:32:25 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21734; Thu, 8 Jul 93 23:31:07 -0400 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA13747; Thu, 8 Jul 93 20:31:02 PDT Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA24053; Thu, 8 Jul 93 23:30:34 EDT Message-Id: <9307090330.AA24053@tweedledumb.cygnus.com> To: Don Beusee Cc: rdist-dev@usc.edu, todd@meaddata.com Subject: Re: question on setreuid() In-Reply-To: Your message of "Thu, 08 Jul 93 19:36:12 PDT." <9307090236.AA21415@dbeusee.us.oracle.com> Date: Thu, 08 Jul 93 23:30:21 -0400 From: raeburn@cambridge.cygnus.com Status: R > rcmd() is only allowed when euid=0, since rcmd() is a priviledged operation. Is there anything else that requires root privs? I.e., if rdist is fixed to use Kerberos authentication, is there any other reason for it to be setuid? From dor@acl.lanl.gov Fri Jul 9 08:05:54 1993 Return-Path: Received: from acl.lanl.gov by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08532; Fri, 9 Jul 93 08:05:54 PDT Received: from grizzly.acl.lanl.gov by acl.lanl.gov (5.67/SMI-4.1) id AA13056; Fri, 9 Jul 93 09:05:53 -0600 Received: by grizzly.acl.lanl.gov (5.67/SMI-4.1) id AA27096; Fri, 9 Jul 93 09:05:51 -0600 Date: Fri, 9 Jul 93 09:05:51 -0600 From: dor@acl.lanl.gov (David O. Rich) Message-Id: <9307091505.AA27096@grizzly.acl.lanl.gov> To: yeoak@iscs.nus.sg (Yeo Ann Kian) Cc: rdist-dev@usc.edu Subject: rdist fails at "special" command when running on irix4 In-Reply-To: <9307091017.AA15334@elc1s.iscs.nus.sg> References: <9307091017.AA15334@elc1s.iscs.nus.sg> Yeo> I tried to rdist from "idg4k1s" -> "idg4k2s" to install a file Yeo> "t.sh" and execute "t.sh" when it is installed. Both Yeo> "idg4k[12]s" run IriX4.0.5F. rdist complainted with "REMOTE Yeo> ERROR". The line printed before "REMOTE ERROR" doesn't look Yeo> right to me. Any idea? ... I've been working on debugging this for the past couple of days off and on. The symptoms, for me, showed up when I noticed that "special" commands we're failing on all of our non-Sun hosts (e.g., SGI, FPS, RS6000) but succeeding on all Sun hosts. I've currently tracked the problem down to the execl call in the runcommand routine in common.c. The "environment" in which this is executed seems to cause the /bin/sh to fail for some reason. As a test, I extracted the runcommand code out of common.c and stuffed it into a separate file, bug.c. The same code seems to work without error outside of the rdist code so I'm a bit confused at this point... I hope to have some time today to look more at this problem. Anyone else hacking on this by any chance? Anyone know of some /bin/sh weirdness that might cause this (and which doesn't happen on Sun's)? Just as a note, I replace /bin/sh in the execl call with /bin/csh and hardcoded a command in place and everything worked just fine. Doing the same thing with /bin/sh results in the execl returning -1 and errno set to ENOENT (2). -- David Rich (dor@acl.lanl.gov) Advanced Computing Laboratory From dbeusee@us.oracle.com Fri Jul 9 08:16:05 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09017; Fri, 9 Jul 93 08:16:05 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA11075; Fri, 9 Jul 93 08:12:26 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA23075; Fri, 9 Jul 93 08:07:06 PDT Message-Id: <9307091507.AA23075@dbeusee.us.oracle.com> Date: Fri, 9 Jul 93 08:07:06 PDT From: Don Beusee To: rdist-dev@usc.edu, yeoak@iscs.nus.sg Subject: Re: rdist fails at "special" command when running on irix4 Cc: yeoak@elc1s.iscs.nus.sg The problem is the stupid SETARGS code. Change "#define SETARGS" to "#undef SETARGS". This is in config/os-*.h . I put this undef line in my config/config.h to cover all platforms. From yeoak@iscs.nus.sg Fri Jul 9 04:16:10 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21850; Fri, 9 Jul 93 04:16:08 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA24825; Fri, 9 Jul 93 04:21:24 PDT Received: from nuscc.nus.sg by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29864; Fri, 9 Jul 93 03:23:44 PDT Received: from sun.iscs.nus.sg by nuscc.nus.sg (5.65/1.34) id AA25729; Fri, 9 Jul 93 18:19:04 +0800 Received: from elc1s.iscs.nus.sg by sun.iscs.nus.sg with SMTP id AA22733 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 18:18:34 +0800 Received: by elc1s.iscs.nus.sg (4.1/SMI-4.1) id AA15334; Fri, 9 Jul 93 18:17:14 SST From: yeoak@iscs.nus.sg (Yeo Ann Kian) Message-Id: <9307091017.AA15334@elc1s.iscs.nus.sg> Subject: rdist fails at "special" command when running on irix4 To: rdist-dev@usc.edu Date: Fri, 9 Jul 93 18:17:13 WST Cc: yeoak@elc1s.iscs.nus.sg (Yeo Ann Kian) X-Mailer: ELM [version 2.3 PL11] Status: R I tried to rdist from "idg4k1s" -> "idg4k2s" to install a file "t.sh" and execute "t.sh" when it is installed. Both "idg4k[12]s" run IriX4.0.5F. rdist complainted with "REMOTE ERROR". The line printed before "REMOTE ERROR" doesn't look right to me. Any idea? -------------------------------------------------------------------------- > rdist -f t.cf idg4k2s: updating host idg4k2s idg4k2s: /home/root/idg/t.sh: updating idg4k2s: special "/home/root/idg/t.sh" idg4k2s: k1s.iscs.nus.sg : is not an identifier idg4k2s: REMOTE ERROR: shell returned 256 idg4k2s: updating of idg4k2s finished >rdist -V Version 6.1beta.1 - Protocol Version 6, Release 6.1beta, Patch level 1 >cat t.cf # # File: t.cf HOSTS = ( idg4k2s ) FILES = ( /home/root/idg/t.sh ) ${FILES} -> ${HOSTS} install ; special "/home/root/idg/t.sh" ; >cat t.sh #!/bin/sh /bin/touch /tmp/ttt -- Ann-Kian Yeo Internet: yeoak@iscs.nus.sg 772-2780 Dept. of Information Systems and Computer Science (DISCS), NUS, Singapore From dbeusee@us.oracle.com Fri Jul 9 08:39:40 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09809; Fri, 9 Jul 93 08:39:40 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA13294; Fri, 9 Jul 93 08:38:09 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA23169; Fri, 9 Jul 93 08:32:49 PDT Message-Id: <9307091532.AA23169@dbeusee.us.oracle.com> Date: Fri, 9 Jul 93 08:32:49 PDT From: Don Beusee To: dor@acl.lanl.gov, yeoak@iscs.nus.sg Subject: Re: rdist fails at "special" command when running on irix4 Cc: rdist-dev@usc.edu Basically, the SETARGS code only works on SUNS. It fails on almost all other platforms, causing problems like this one. Simply #undef SETARGS and the problem will go away. From dor@acl.lanl.gov Fri Jul 9 08:16:48 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA23101; Fri, 9 Jul 93 08:16:47 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA11965; Fri, 9 Jul 93 08:22:02 PDT Received: from acl.lanl.gov by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08532; Fri, 9 Jul 93 08:05:54 PDT Received: from grizzly.acl.lanl.gov by acl.lanl.gov (5.67/SMI-4.1) id AA13056; Fri, 9 Jul 93 09:05:53 -0600 Received: by grizzly.acl.lanl.gov (5.67/SMI-4.1) id AA27096; Fri, 9 Jul 93 09:05:51 -0600 Date: Fri, 9 Jul 93 09:05:51 -0600 From: dor@acl.lanl.gov (David O. Rich) Message-Id: <9307091505.AA27096@grizzly.acl.lanl.gov> To: yeoak@iscs.nus.sg (Yeo Ann Kian) Cc: rdist-dev@usc.edu Subject: rdist fails at "special" command when running on irix4 In-Reply-To: <9307091017.AA15334@elc1s.iscs.nus.sg> References: <9307091017.AA15334@elc1s.iscs.nus.sg> Status: R Yeo> I tried to rdist from "idg4k1s" -> "idg4k2s" to install a file Yeo> "t.sh" and execute "t.sh" when it is installed. Both Yeo> "idg4k[12]s" run IriX4.0.5F. rdist complainted with "REMOTE Yeo> ERROR". The line printed before "REMOTE ERROR" doesn't look Yeo> right to me. Any idea? ... I've been working on debugging this for the past couple of days off and on. The symptoms, for me, showed up when I noticed that "special" commands we're failing on all of our non-Sun hosts (e.g., SGI, FPS, RS6000) but succeeding on all Sun hosts. I've currently tracked the problem down to the execl call in the runcommand routine in common.c. The "environment" in which this is executed seems to cause the /bin/sh to fail for some reason. As a test, I extracted the runcommand code out of common.c and stuffed it into a separate file, bug.c. The same code seems to work without error outside of the rdist code so I'm a bit confused at this point... I hope to have some time today to look more at this problem. Anyone else hacking on this by any chance? Anyone know of some /bin/sh weirdness that might cause this (and which doesn't happen on Sun's)? Just as a note, I replace /bin/sh in the execl call with /bin/csh and hardcoded a command in place and everything worked just fine. Doing the same thing with /bin/sh results in the execl returning -1 and errno set to ENOENT (2). -- David Rich (dor@acl.lanl.gov) Advanced Computing Laboratory From mcooper@acamar.usc.edu Fri Jul 9 10:05:34 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13044; Fri, 9 Jul 93 10:05:34 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA04096; Fri, 9 Jul 93 10:05:22 PDT Sender: "Michael A. Cooper" Date: Fri, 9 Jul 93 10:05:22 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: raeburn@cambridge.cygnus.com Cc: Don Beusee , rdist-dev@usc.edu, todd@meaddata.com Subject: Re: question on setreuid() In-Reply-To: Your message of Thu, 08 Jul 93 23:30:21 -0400 Message-Id: Content-Length: 471 > > > rcmd() is only allowed when euid=0, since rcmd() is a priviledged operation. > > Is there anything else that requires root privs? > > I.e., if rdist is fixed to use Kerberos authentication, is there any > other reason for it to be setuid? > The _ONLY_ reason rdist is setuid root is the rcmd() stuff. This is due to rcmd() binding to a priv'ed port. If you have a replacement for rcmd() that doesn't need priv's, then rdist doesn't need to be setuid. mike From mcooper@acamar.usc.edu Fri Jul 9 10:16:57 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13483; Fri, 9 Jul 93 10:16:57 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA04483; Fri, 9 Jul 93 10:16:43 PDT Sender: "Michael A. Cooper" Date: Fri, 9 Jul 93 10:16:43 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: dor@acl.lanl.gov (David O. Rich) Cc: yeoak@iscs.nus.sg (Yeo Ann Kian), rdist-dev@usc.edu Subject: Re: rdist fails at "special" command when running on irix4 In-Reply-To: Your message of Fri, 9 Jul 93 09:05:51 -0600 Message-Id: Content-Length: 106 The setargs code causes this condition on many platforms. Undefine SETARGS and it should be fine. mike From yeoak@iscs.nus.sg Fri Jul 9 20:16:24 1993 Return-Path: Received: from nuscc.nus.sg by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05391; Fri, 9 Jul 93 20:16:24 PDT Received: from sun.iscs.nus.sg by nuscc.nus.sg (5.65/1.34) id AA11447; Sat, 10 Jul 93 11:16:19 +0800 Received: from elc1s.iscs.nus.sg by sun.iscs.nus.sg with SMTP id AA27812 (5.65c/IDA-1.4.4 for ); Sat, 10 Jul 1993 11:15:49 +0800 Received: by elc1s.iscs.nus.sg (4.1/SMI-4.1) id AA18426; Sat, 10 Jul 93 11:14:28 SST From: yeoak@iscs.nus.sg (Yeo Ann Kian) Message-Id: <9307100314.AA18426@elc1s.iscs.nus.sg> Subject: Re: rdist fails at "special" command To: rdist-dev@usc.edu Date: Sat, 10 Jul 93 11:14:27 WST Cc: yeoak@elc1s.iscs.nus.sg (Yeo Ann Kian) X-Mailer: ELM [version 2.3 PL11] Thanks for all those who have replied. I have run "make" again with #undef SETARGS in config/os-irix4.h. "special" and "cmdspecial" now works when rdists between two irix4.0.5Fs. It works between SunOS4.x and irix4.0.5F as well. -- Ann-Kian Yeo Internet: yeoak@iscs.nus.sg 772-2780 Dept. of Information Systems and Computer Science (DISCS), NUS, Singapore From neal@ctd.comsat.com Thu Jul 15 07:42:06 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05971; Thu, 15 Jul 93 07:42:06 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oGUVX-0003UmC; Thu, 15 Jul 93 10:42 EDT Message-Id: Date: Thu, 15 Jul 93 10:42 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: catastrophic failures I have observered a number of instances where a single failure of rdist causes the entire rdist to fail. Typically, this involves a failed install due to text file busy on hpux, which can occur in a couple of ways ( one way is that a previous rdist renamed file->file.OLD, and a new rdist wants to update a second time but file.OLD is still in use ). Here is an example: data: REMOTE ERROR: /src/local/lib/plan/pland.OLD: unlink failed: Text file busy data: LOCAL ERROR: /src/local/lib/plan/pland.OLD: opendir failed: No such file or directory data: LOCAL ERROR: update: unexpected response '' data: QX11 data: /src/local/lib/kit: installing data: N data: /src/local/lib/plan/kit: mkdir data: LOCAL ERROR: update: unexpected response '' data: /src/local/lib/gopher: installing data: N data: /src/local/lib/plan/kit/gopher: mkdir data: LOCAL ERROR: update: unexpected response '' data: /src/local/lib/news: installing The problem here is that the single failure causes a cascade of errors for every file that follows. Is there any way to fix this? Thanks. From neal@ctd.comsat.com Thu Jul 15 08:02:28 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06905; Thu, 15 Jul 93 08:02:28 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oGUpH-0003UmC; Thu, 15 Jul 93 11:02 EDT Message-Id: Date: Thu, 15 Jul 93 11:02 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: References: The previously cited problem began with a failure of unlink, due to the use of -oremove, which caused unlink to fail with ETXTBSY. How does this patch strike you? =================================================================== RCS file: RCS/server.c,v retrieving revision 1.1 diff -c -r1.1 server.c *** 1.1 1993/07/15 14:57:28 --- server.c 1993/07/15 14:59:42 *************** *** 283,290 **** --- 283,294 ---- case S_IFREG: case S_IFLNK: if (unlink(target) < 0) { + if( errno == ETXTBSY ) + message(MT_NOTICE, "%s: unlink failed (ETXTBSY)", target ); + else { error("%s: unlink failed: %s", target, SYSERR); return(-1); + } } goto removed; From neal@ctd.comsat.com Thu Jul 15 08:26:44 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07889; Thu, 15 Jul 93 08:26:44 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oGVCl-0003UmC; Thu, 15 Jul 93 11:26 EDT Message-Id: Date: Thu, 15 Jul 93 11:26 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: References: This patch seems to do the trick: *** 1.1 1993/07/15 14:57:28 --- server.c 1993/07/15 15:23:09 *************** *** 283,290 **** --- 283,296 ---- case S_IFREG: case S_IFLNK: if (unlink(target) < 0) { + if( errno == ETXTBSY ) { + message(MT_REMOTE|MT_NOTICE, "%s: unlink failed (ETXTBSY)", target ); + return( 0 ); + } + else { error("%s: unlink failed: %s", target, SYSERR); return(-1); + } } goto removed; From dbeusee@us.oracle.com Thu Jul 15 09:15:09 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09698; Thu, 15 Jul 93 09:15:09 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA03879; Thu, 15 Jul 93 09:15:06 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06612; Thu, 15 Jul 93 09:09:50 PDT Message-Id: <9307151609.AA06612@dbeusee.us.oracle.com> Date: Thu, 15 Jul 93 09:09:50 PDT From: Don Beusee To: neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: catastrophic failures This is not the solution to the problem where rdist gets out of sync due to error() being used instead of message(MT_NOTICE, ..). Using error() should not cause the rdist client and server to get out of sync. From neal@ctd.comsat.com Thu Jul 15 08:15:39 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06384; Thu, 15 Jul 93 08:15:38 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA00609; Thu, 15 Jul 93 08:20:50 PDT Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06905; Thu, 15 Jul 93 08:02:28 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oGUpH-0003UmC; Thu, 15 Jul 93 11:02 EDT Message-Id: Date: Thu, 15 Jul 93 11:02 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: References: Status: R The previously cited problem began with a failure of unlink, due to the use of -oremove, which caused unlink to fail with ETXTBSY. How does this patch strike you? =================================================================== RCS file: RCS/server.c,v retrieving revision 1.1 diff -c -r1.1 server.c *** 1.1 1993/07/15 14:57:28 --- server.c 1993/07/15 14:59:42 *************** *** 283,290 **** --- 283,294 ---- case S_IFREG: case S_IFLNK: if (unlink(target) < 0) { + if( errno == ETXTBSY ) + message(MT_NOTICE, "%s: unlink failed (ETXTBSY)", target ); + else { error("%s: unlink failed: %s", target, SYSERR); return(-1); + } } goto removed; From neal@ctd.comsat.com Thu Jul 15 10:47:09 1993 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13551; Thu, 15 Jul 93 10:47:09 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #18) id m0oGXOG-0003UmC; Thu, 15 Jul 93 13:46 EDT Message-Id: Date: Thu, 15 Jul 93 13:46 EDT From: neal@ctd.comsat.com (Neal Becker) To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: <9307151609.AA06612@dbeusee.us.oracle.com> References: <9307151609.AA06612@dbeusee.us.oracle.com> >>>>> On Thu, 15 Jul 93 09:09:50 PDT, Don Beusee said: Don> This is not the solution to the problem where rdist gets Don> out of sync due to error() being used instead of Don> message(MT_NOTICE, ..). Using error() should not cause Don> the rdist client and server to get out of sync. >From neal@ctd.comsat.com Thu Jul 15 08:15:39 1993 Don> The previously cited problem began with a failure of unlink, due to Don> the use of -oremove, which caused unlink to fail with ETXTBSY. How Don> does this patch strike you? [...] Don is correct. I should explain. I am trying to fix 2 different problems. 1). rdist gets out of sync and fails all subsequent stuff. I have no idea how to fix this, and I sure hope someone else can figure it out. 2). ETXTBSY interferes with -oremove on some hosts. The last patch I posted should fix this (without causing some new gotcha, I think). From mcooper@acamar.usc.edu Thu Jul 15 12:27:35 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17876; Thu, 15 Jul 93 12:27:35 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA00810; Thu, 15 Jul 93 12:27:22 PDT Sender: "Michael A. Cooper" Date: Thu, 15 Jul 93 12:27:21 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: Your message of Thu, 15 Jul 93 10:42 EDT Message-Id: Content-Length: 283 Rdist has always been very fragile when it comes to errors like this. Without changing the protocol, the only real thing that can be done is iterate over the most common types of errors (using errno) and deal with the accordingly. Just another reason for a total re-write. mike From dbeusee@us.oracle.com Thu Jul 15 13:11:44 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20233; Thu, 15 Jul 93 13:11:44 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA19435; Thu, 15 Jul 93 13:11:21 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07062; Thu, 15 Jul 93 13:06:06 PDT Message-Id: <9307152006.AA07062@dbeusee.us.oracle.com> Date: Thu, 15 Jul 93 13:06:06 PDT From: Don Beusee To: mcooper@usc.edu, neal@ctd.comsat.com Subject: Re: catastrophic failures Cc: rdist-dev@usc.edu But V4 never had this problem! It seemed to recover nicely. From mcooper@acamar.usc.edu Thu Jul 15 12:58:40 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07041; Thu, 15 Jul 93 12:58:34 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA18908; Thu, 15 Jul 93 13:03:47 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17876; Thu, 15 Jul 93 12:27:35 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA00810; Thu, 15 Jul 93 12:27:22 PDT Sender: "Michael A. Cooper" Date: Thu, 15 Jul 93 12:27:21 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: Your message of Thu, 15 Jul 93 10:42 EDT Message-Id: Content-Length: 283 Status: R Rdist has always been very fragile when it comes to errors like this. Without changing the protocol, the only real thing that can be done is iterate over the most common types of errors (using errno) and deal with the accordingly. Just another reason for a total re-write. mike From mcooper@acamar.usc.edu Thu Jul 15 13:59:38 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22722; Thu, 15 Jul 93 13:59:38 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA01408; Thu, 15 Jul 93 13:59:28 PDT Sender: "Michael A. Cooper" Date: Thu, 15 Jul 93 13:59:27 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: catastrophic failures In-Reply-To: Your message of Thu, 15 Jul 93 13:06:06 PDT Message-Id: Content-Length: 231 That's quite possible. What I was trying to say is that it's rdist is fragile in that whenever new functionality is added, it's fairly easy to introduce cases like this when you're always trying not to change the protocol. mike From dbeusee@us.oracle.com Thu Jul 22 09:02:30 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08043; Thu, 22 Jul 93 09:02:30 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA27423; Thu, 22 Jul 93 09:02:23 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22237; Thu, 22 Jul 93 08:57:11 PDT Message-Id: <9307221557.AA22237@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 08:57:11 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: Unexpected input at startup THis is NOT a LOCAL ERROR: erseq3: LOCAL ERROR: Unexpected input at startup: "ksh: /usr/local/bin/rdistd: not found". This stops the rdist from continuing with other hosts. I cannot do parallel rdist's (I am using -F) because it is still broken. Regards, Don. From aad@siemens.siemens.com Thu Jul 22 09:31:47 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09028; Thu, 22 Jul 93 09:31:47 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0oJ3YX-0019W5C; Thu, 22 Jul 93 12:31 EDT Received: by lovecraft (4.1/SMI-4.1) id AA21603; Thu, 22 Jul 93 12:31:44 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Thu, 22 Jul 1993 12:31:44 -0400 (EDT) Message-Id: Date: Thu, 22 Jul 1993 12:31:44 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: <9307221557.AA22237@dbeusee.us.oracle.com> References: <9307221557.AA22237@dbeusee.us.oracle.com> >erseq3: LOCAL ERROR: Unexpected input at startup: "ksh: /usr/local/bin/rdistd: not found". My boss had this problem. If I remember correctly, ksh refuses to process .profile or .kshrc or whatever when run non-interactively. I ended up just hardcoding the path to rdistd to satisfy him. ======================================================================8--< From warrenv@dadd.ti.com Thu Jul 22 09:39:33 1993 Return-Path: Received: from ti.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09236; Thu, 22 Jul 93 09:39:33 PDT Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA25293; Thu, 22 Jul 1993 11:46:24 -0500 Received: from sys_admin4 (dadsg1.dadd.ti.com) by tilde.csc.ti.com id AA04898; Thu, 22 Jul 1993 11:38:14 -0500 Received: from beatnik.dadd.ti.com by sys_admin4 (4.1/SMI-4.1) id AA15092; Thu, 22 Jul 93 11:30:33 CDT From: warrenv@dadd.ti.com (Warren Vosper) Received: by beatnik.dadd.ti.com id ; Thu, 22 Jul 93 11:36:42 -0500 Message-Id: <9307221636.AA24041@beatnik.dadd.ti.com> Subject: Re: Unexpected input at startup To: rdist-dev@usc.edu Date: Thu, 22 Jul 1993 11:36:42 -0600 (CDT) In-Reply-To: <9307221557.AA22237@dbeusee.us.oracle.com> from "Don Beusee" at Jul 22, 93 08:57:11 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 554 > > THis is NOT a LOCAL ERROR: > > erseq3: LOCAL ERROR: Unexpected input at startup: "ksh: /usr/local/bin/rdistd: not found". > I'm getting this also (with a csh). /usr/local/bin/rdistd exists so what can't if find?? -- ===================================================== | Warren R. Vosper | warrenv@lobby.ti.com | | Design Automation Division | | | Texas Instruments, Inc. | TI msg id: VOSP | | Dallas, TX | Phone: (214)917-3932 | ===================================================== From aad@siemens.siemens.com Thu Jul 22 09:56:18 1993 Return-Path: Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09966; Thu, 22 Jul 93 09:56:18 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0oJ3wH-0019WEC; Thu, 22 Jul 93 12:56 EDT Received: by lovecraft (4.1/SMI-4.1) id AA21773; Thu, 22 Jul 93 12:56:17 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Thu, 22 Jul 1993 12:56:16 -0400 (EDT) Message-Id: Date: Thu, 22 Jul 1993 12:56:16 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: <9307221636.AA24041@beatnik.dadd.ti.com> References: <9307221636.AA24041@beatnik.dadd.ti.com> > I'm getting this also (with a csh). /usr/local/bin/rdistd exists so >what can't if find?? rdist v6 by default expects to find rdistd along the shell's search path. Chances are that the remote user augments the path in .login instead of .cshrc. Non-login invocations of csh only read .cshrc, and thus wouldn't get the path augmentation. I've seen these kinds of problems for years, and have always tried to get people to do their stuff in .cshrc instead of .login. ======================================================================8--< From dbeusee@us.oracle.com Thu Jul 22 10:45:06 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11834; Thu, 22 Jul 93 10:45:06 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA05598; Thu, 22 Jul 93 10:45:04 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22434; Thu, 22 Jul 93 10:39:52 PDT Message-Id: <9307221739.AA22434@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 10:39:52 PDT From: Don Beusee To: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: Unexpected input at startup I used a hard-coded path as you can see by the error. The issue is that this system did not have it installed and aborted the rest of the systems due to this "LOCAL ERROR", which is really a REMOTE ERROR. From aad@siemens.siemens.com Thu Jul 22 09:41:22 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22318; Thu, 22 Jul 93 09:41:20 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA00843; Thu, 22 Jul 93 09:46:28 PDT Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09028; Thu, 22 Jul 93 09:31:47 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0oJ3YX-0019W5C; Thu, 22 Jul 93 12:31 EDT Received: by lovecraft (4.1/SMI-4.1) id AA21603; Thu, 22 Jul 93 12:31:44 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Thu, 22 Jul 1993 12:31:44 -0400 (EDT) Message-Id: Date: Thu, 22 Jul 1993 12:31:44 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: <9307221557.AA22237@dbeusee.us.oracle.com> References: <9307221557.AA22237@dbeusee.us.oracle.com> Status: R >erseq3: LOCAL ERROR: Unexpected input at startup: "ksh: /usr/local/bin/rdistd: not found". My boss had this problem. If I remember correctly, ksh refuses to process .profile or .kshrc or whatever when run non-interactively. I ended up just hardcoding the path to rdistd to satisfy him. ======================================================================8--< From dbeusee@us.oracle.com Thu Jul 22 10:54:13 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12218; Thu, 22 Jul 93 10:54:13 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA06233; Thu, 22 Jul 93 10:54:11 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22472; Thu, 22 Jul 93 10:48:58 PDT Message-Id: <9307221748.AA22472@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 10:48:58 PDT From: Don Beusee To: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: Unexpected input at startup PATH settings do not belong in .cshrc, because sub-shells (and therefore scripts) will run with a different PATH than expected. In any case, I am not complaining that it should find it (it is in fact missing on that system), but that it stopped rdisting to the rest of the machines. Regards, Don. From aad@siemens.siemens.com Thu Jul 22 10:03:35 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22370; Thu, 22 Jul 93 10:03:34 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA02677; Thu, 22 Jul 93 10:08:41 PDT Received: from siemens.siemens.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09966; Thu, 22 Jul 93 09:56:18 PDT Received: from lovecraft by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0oJ3wH-0019WEC; Thu, 22 Jul 93 12:56 EDT Received: by lovecraft (4.1/SMI-4.1) id AA21773; Thu, 22 Jul 93 12:56:17 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.siemens.com.sun4.41 via MS.5.6.lovecraft.siemens.com.sun4_41; Thu, 22 Jul 1993 12:56:16 -0400 (EDT) Message-Id: Date: Thu, 22 Jul 1993 12:56:16 -0400 (EDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: <9307221636.AA24041@beatnik.dadd.ti.com> References: <9307221636.AA24041@beatnik.dadd.ti.com> Status: R > I'm getting this also (with a csh). /usr/local/bin/rdistd exists so >what can't if find?? rdist v6 by default expects to find rdistd along the shell's search path. Chances are that the remote user augments the path in .login instead of .cshrc. Non-login invocations of csh only read .cshrc, and thus wouldn't get the path augmentation. I've seen these kinds of problems for years, and have always tried to get people to do their stuff in .cshrc instead of .login. ======================================================================8--< From dbeusee@us.oracle.com Thu Jul 22 12:02:56 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01003; Thu, 22 Jul 93 12:02:56 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA10769; Thu, 22 Jul 93 11:44:18 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22693; Thu, 22 Jul 93 11:39:06 PDT Message-Id: <9307221839.AA22693@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 11:39:06 PDT From: Don Beusee To: raeburn@cambridge.cygnus.com Subject: Re: Unexpected input at startup Cc: aad@lovecraft.siemens.com, rdist-dev@usc.edu This is a religious war which I don't care to fight. Some sites keep unix defaults for rsh commands and only alter the path from .login for interactive users. Any local commands executed with an rsh command can be fully qualified with a complete path, like I have done with rdistd so that it would not matter what the path looks like on the remote system, which is impossible to predict unless you are the only person on the planet with access to change the ~/.cshrc. Regards, Don. From raeburn@cambridge.cygnus.com Thu Jul 22 11:29:12 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22660; Thu, 22 Jul 93 11:29:11 PDT Received: from relay1.UU.NET by gatekeeper.oracle.com (5.59.11/37.7) id AA09780; Thu, 22 Jul 93 11:34:18 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28984; Thu, 22 Jul 93 14:31:34 -0400 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA06812; Thu, 22 Jul 93 11:31:24 PDT Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA13059; Thu, 22 Jul 93 14:30:39 EDT Message-Id: <9307221830.AA13059@tweedledumb.cygnus.com> To: Don Beusee Cc: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: Your message of "Thu, 22 Jul 93 10:48:58 PDT." <9307221748.AA22472@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 14:30:08 -0400 From: raeburn@cambridge.cygnus.com Status: R > PATH settings do not belong in .cshrc, because sub-shells (and therefore > scripts) will run with a different PATH than expected. On the other hand, if they aren't there, the "rsh" environment has a different PATH than normal login sessions. This isn't a new problem... The solution I usually use is to set an environment variable that indicates whether my path has already been set properly; if it's set, my .cshrc doesn't change the environment it finds, so any modifications from my defaults that I've made for this session stay in effect in subshells. And rsh still gets my default environment, rather than the defaults coded into rshd and csh. From raeburn@cambridge.cygnus.com Thu Jul 22 12:09:13 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01319; Thu, 22 Jul 93 12:09:13 PDT Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28984; Thu, 22 Jul 93 14:31:34 -0400 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA06812; Thu, 22 Jul 93 11:31:24 PDT Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA13059; Thu, 22 Jul 93 14:30:39 EDT Message-Id: <9307221830.AA13059@tweedledumb.cygnus.com> To: Don Beusee Cc: aad@lovecraft.siemens.com, rdist-dev@usc.edu Subject: Re: Unexpected input at startup In-Reply-To: Your message of "Thu, 22 Jul 93 10:48:58 PDT." <9307221748.AA22472@dbeusee.us.oracle.com> Date: Thu, 22 Jul 93 14:30:08 -0400 From: raeburn@cambridge.cygnus.com > PATH settings do not belong in .cshrc, because sub-shells (and therefore > scripts) will run with a different PATH than expected. On the other hand, if they aren't there, the "rsh" environment has a different PATH than normal login sessions. This isn't a new problem... The solution I usually use is to set an environment variable that indicates whether my path has already been set properly; if it's set, my .cshrc doesn't change the environment it finds, so any modifications from my defaults that I've made for this session stay in effect in subshells. And rsh still gets my default environment, rather than the defaults coded into rshd and csh. From rsalz@osf.org Thu Jul 22 12:12:07 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01424; Thu, 22 Jul 93 12:12:07 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA29911; Thu, 22 Jul 93 15:11:55 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA18964; Thu, 22 Jul 93 15:13:08 -0400 Date: Thu, 22 Jul 93 15:13:08 -0400 From: rsalz@osf.org Message-Id: <9307221913.AA18964@sulphur.osf.org> To: dbeusee@us.oracle.com, raeburn@cambridge.cygnus.com Subject: Re: Unexpected input at startup Cc: aad@lovecraft.siemens.com, rdist-dev@usc.edu Run a real shell like rc and the problem goes away. :-) From dbeusee@us.oracle.com Sat Jul 24 11:30:57 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08857; Sat, 24 Jul 93 11:30:57 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA26024; Sat, 24 Jul 93 11:30:55 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29307; Sat, 24 Jul 93 11:25:44 PDT Message-Id: <9307241825.AA29307@dbeusee.us.oracle.com> Date: Sat, 24 Jul 93 11:25:44 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: patch for parallel rdist The following patch to child.c fixes some random hosts not getting updated when doing parallel rdisting (no -F used): 480a481,482 > > sleep(2); /* must give child a chance to start */ For some reason, if the parent exits the spawn() routine before the child starts, the child looses. Strange that it does not happen if I use -M50 and 49 hosts are involved. But this patch does make it much more reliable. Regards, Don. From dbeusee@us.oracle.com Sat Jul 24 12:18:10 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10148; Sat, 24 Jul 93 12:18:10 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA27256; Sat, 24 Jul 93 12:18:08 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29418; Sat, 24 Jul 93 12:12:57 PDT Message-Id: <9307241912.AA29418@dbeusee.us.oracle.com> Date: Sat, 24 Jul 93 12:12:57 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: Re: patch for parallel rdist I think I better use diff -c format. So here is the same patch in diff -c format: *** 1.1 1993/07/24 18:10:06 --- child.c 1993/07/24 18:18:19 *************** *** 478,483 **** --- 478,485 ---- * Parent */ static CHILD newchild; + + sleep(2); /* must give child a chance to start */ /* Receive notification when the child exits */ (void) signal(SIGCHLD, reap); Regards, Don. From dbeusee@us Sat Jul 24 11:53:16 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29392; Sat, 24 Jul 93 11:53:15 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA26660; Sat, 24 Jul 93 11:58:22 PDT Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08857; Sat, 24 Jul 93 11:30:57 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA26024; Sat, 24 Jul 93 11:30:55 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29307; Sat, 24 Jul 93 11:25:44 PDT Message-Id: <9307241825.AA29307@dbeusee.us.oracle.com> Date: Sat, 24 Jul 93 11:25:44 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: patch for parallel rdist Status: R The following patch to child.c fixes some random hosts not getting updated when doing parallel rdisting (no -F used): 480a481,482 > > sleep(2); /* must give child a chance to start */ For some reason, if the parent exits the spawn() routine before the child starts, the child looses. Strange that it does not happen if I use -M50 and 49 hosts are involved. But this patch does make it much more reliable. Regards, Don. From mcooper@acamar.usc.edu Mon Jul 26 13:43:05 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29607; Mon, 26 Jul 93 13:43:05 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA11544; Mon, 26 Jul 93 13:42:49 PDT Sender: "Michael A. Cooper" Date: Mon, 26 Jul 93 13:42:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: patch for parallel rdist In-Reply-To: Your message of Sat, 24 Jul 93 12:12:57 PDT Message-Id: Content-Length: 180 Hmmm. There must be some other cause of the problem if a sleep() makes it work. I'll have to look into this more. Thanks for taking the time to track it down this far! mike From dbeusee@us.oracle.com Mon Jul 26 15:34:01 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04208; Mon, 26 Jul 93 15:34:01 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA03026; Mon, 26 Jul 93 15:33:58 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04527; Mon, 26 Jul 93 15:28:48 PDT Message-Id: <9307262228.AA04527@dbeusee.us.oracle.com> Date: Mon, 26 Jul 93 15:28:48 PDT From: Don Beusee To: mcooper@usc.edu Subject: Re: patch for parallel rdist Cc: rdist-dev@usc.edu Without the sleep, the child sometimes does not return from the spawn() routine. Once in a while, it does not return from the fork() either even thought the parent got a pid for it!! i.e. I got more pid numbers than 0 pids (children). I put debugmsg()'s before and after spawn() and fork(). Very strange problem. Could be a resource problem not properly reported by fork(). But it might be likely that fork() is not completely re-entrant. i.e. maybe the parent colides with the previously fork'd child that has not left fork() yet... Regards, Don. From mcooper@acamar.usc.edu Mon Jul 26 14:28:45 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA04280; Mon, 26 Jul 93 14:28:44 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA29163; Mon, 26 Jul 93 14:33:50 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29607; Mon, 26 Jul 93 13:43:05 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA11544; Mon, 26 Jul 93 13:42:49 PDT Sender: "Michael A. Cooper" Date: Mon, 26 Jul 93 13:42:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: patch for parallel rdist In-Reply-To: Your message of Sat, 24 Jul 93 12:12:57 PDT Message-Id: Content-Length: 180 Status: R Hmmm. There must be some other cause of the problem if a sleep() makes it work. I'll have to look into this more. Thanks for taking the time to track it down this far! mike From mcooper@acamar.usc.edu Tue Jul 27 16:31:42 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25227; Tue, 27 Jul 93 16:31:42 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA19734; Tue, 27 Jul 93 16:31:32 PDT Sender: "Michael A. Cooper" Date: Tue, 27 Jul 93 16:31:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: patch for parallel rdist In-Reply-To: Your message of Sat, 24 Jul 93 12:12:57 PDT Message-Id: Content-Length: 2165 I still don't like just putting a sleep() call in. I did find some casting problems that could mask an error from fork(). Please apply the patch below _without_ the sleep() call and let me know if the problem still persists. mike *** /tmp/T0a004o2 Tue Jul 27 16:29:10 1993 --- /tmp/T1a004o2 Tue Jul 27 16:29:10 1993 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.18 1993/07/15 22:48:58 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.19 1993/07/27 23:27:44 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 65,71 **** struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! int c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; --- 65,71 ---- struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! pid_t c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; *************** *** 274,280 **** static void reap() { register CHILD *pc; ! int status = 0, pid; debugmsg(DM_CALL, "reap() called\n"); --- 274,281 ---- static void reap() { register CHILD *pc; ! int status = 0; ! pid_t pid; debugmsg(DM_CALL, "reap() called\n"); *************** *** 459,465 **** struct cmd *cmd; struct cmd *cmdlist; { ! int pid; int fildes[2]; char *childname = cmd->c_name; --- 460,466 ---- struct cmd *cmd; struct cmd *cmdlist; { ! pid_t pid; int fildes[2]; char *childname = cmd->c_name; *************** *** 469,475 **** } pid = fork(); ! if (pid == -1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); --- 470,476 ---- } pid = fork(); ! if (pid == (pid_t)-1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); From dbeusee@us.oracle.com Tue Jul 27 18:42:28 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29912; Tue, 27 Jul 93 18:42:28 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA20568; Tue, 27 Jul 93 18:42:26 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08534; Tue, 27 Jul 93 18:37:17 PDT Message-Id: <9307280137.AA08534@dbeusee.us.oracle.com> Date: Tue, 27 Jul 93 18:37:17 PDT From: Don Beusee To: mcooper@usc.edu Subject: Re: patch for parallel rdist Cc: rdist-dev@usc.edu I don't think it will matter, since pid_t is an int on SunOS... From mcooper@acamar.usc.edu Tue Jul 27 16:46:21 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08201; Tue, 27 Jul 93 16:46:19 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA13911; Tue, 27 Jul 93 16:51:22 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25227; Tue, 27 Jul 93 16:31:42 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA19734; Tue, 27 Jul 93 16:31:32 PDT Sender: "Michael A. Cooper" Date: Tue, 27 Jul 93 16:31:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: patch for parallel rdist In-Reply-To: Your message of Sat, 24 Jul 93 12:12:57 PDT Message-Id: Content-Length: 2165 Status: R I still don't like just putting a sleep() call in. I did find some casting problems that could mask an error from fork(). Please apply the patch below _without_ the sleep() call and let me know if the problem still persists. mike *** /tmp/T0a004o2 Tue Jul 27 16:29:10 1993 --- /tmp/T1a004o2 Tue Jul 27 16:29:10 1993 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.18 1993/07/15 22:48:58 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.19 1993/07/27 23:27:44 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 65,71 **** struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! int c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; --- 65,71 ---- struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! pid_t c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; *************** *** 274,280 **** static void reap() { register CHILD *pc; ! int status = 0, pid; debugmsg(DM_CALL, "reap() called\n"); --- 274,281 ---- static void reap() { register CHILD *pc; ! int status = 0; ! pid_t pid; debugmsg(DM_CALL, "reap() called\n"); *************** *** 459,465 **** struct cmd *cmd; struct cmd *cmdlist; { ! int pid; int fildes[2]; char *childname = cmd->c_name; --- 460,466 ---- struct cmd *cmd; struct cmd *cmdlist; { ! pid_t pid; int fildes[2]; char *childname = cmd->c_name; *************** *** 469,475 **** } pid = fork(); ! if (pid == -1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); --- 470,476 ---- } pid = fork(); ! if (pid == (pid_t)-1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); From dbeusee@us.oracle.com Wed Jul 28 21:05:49 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27178; Wed, 28 Jul 93 21:05:49 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA01372; Wed, 28 Jul 93 21:05:47 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA13008; Wed, 28 Jul 93 21:00:36 PDT Message-Id: <9307290400.AA13008@dbeusee.us.oracle.com> Date: Wed, 28 Jul 93 21:00:36 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: remfilename patch for rdist 6.1.b1 I found one case where $REMFILE (and $BASENAME) was not set correctly. This also affects the hardlink code. Here is a patch that fixes this. Apply it to client.c (you need my other 6.1.b1 patches): *** 1.6 1993/04/07 15:05:59 --- client.c 1993/07/29 00:41:12 *************** *** 97,104 **** if (cp == NULL) (void) sprintf(buff, "%s/%s", dest, path); else { ! cp = path; ! cp += strlen(src); if ((*cp != '/') && *cp) (void) sprintf(buff, "%s/%s", dest, cp); else --- 97,109 ---- if (cp == NULL) (void) sprintf(buff, "%s/%s", dest, path); else { ! int srclen, pathlen; ! srclen=strlen(src); ! pathlen=strlen(path); ! if (srclen >= pathlen) ! cp++; /* basename(path) */ ! else ! cp = path + srclen; /* path relative to src */ if ((*cp != '/') && *cp) (void) sprintf(buff, "%s/%s", dest, cp); else From mcooper@acamar.usc.edu Mon Aug 2 14:48:13 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12836; Mon, 2 Aug 93 14:48:13 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA18100; Mon, 2 Aug 93 14:48:01 PDT Sender: "Michael A. Cooper" Date: Mon, 2 Aug 93 14:48:00 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist Version 6.1beta.2 Released Cc: cert@cert.org Message-Id: Content-Length: 2951 Rdist version 6.1beta.2 is finally available. I've been incredible busy the last few months and just haven't had time to work on rdist. This release is almost all bug fixes. I've put a hold on adding new features in an effort to get a stable release of 6.1 out the door. I've been running 6.1beta.2 on my machines for about a week or so. So far, no problems have arisen. The big security hole with the old rdist compatibility code is fixed in this release. I've modified the Security.patch2 file out for ftp to read: This problem is present in Rdist version 6 releases, up until version 6.1beta.2, in which the backwards compatibility code for the old Rdist is enabled. Specifically, the bug exists in versions 6.0.X, 6.1beta.0, and 6.1beta.1. The bug is fixed in 6.1beta.2 and in version 6.1.X (when released). Below is the an extract from ChangeLog on changes for this version. mike Mon Aug 2 14:20:14 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Version 6.1beta.2 Thu Jul 29 10:51:54 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix problem that allowed any user with the proper knowledge to gain root access using the backwards compat support for the old rdist. Tue Jul 27 16:27:56 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Use "pid_t" for PID types in child.c. Fri Jul 16 13:32:07 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Don't blow up if removal of a file fails due to ETXTBSY. (Neal Becker) * Don't run cmdspecial's in VERIFY mode. * Increase size of message buffers to 32K. Thu Jul 15 12:53:48 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Fix rdist man page typo's. (Karl Berry) * Take local Makefile's after Makefile.real. (Eric Markwardt) * Add support for new platforms: UNICOS, STELLIX, FPX4. (David O. Rich) * Fix mf.irix4 and os-irix4.h. (David O. Rich) * Set POINTER to char for ultrix4. (David O. Rich) * Add Umax4.3 kludge to isexec.c. (Howie Kaye) * Cause compile time errors if SETFTIME_TYPE is not set. * Declare hasmntopt(). * Add missing pieces to os-mipsos.h and os-irix4.h. (Guessed values) Wed Jul 14 11:12:14 1993 Michael A. Cooper (mcooper@acamar.usc.edu) * Add support for CX/UX. (Done Beusee) * Set SETFTIME_TYPE to SETFTIME_UTIMES for dynix. (Don Beusee) * Fix port to dynixptx. (Don Beusee) * Include if NEED_UTIME_H is defined instead of HPUX. * Enable SETARGS on all platforms. * Fix SETARGS so it should work on most platforms. * Fix a number of pathing problems that occured in 6.1beta.1. (Don Beusee) * Use kill(PID, 0) instead of specific signal to test for a process. * Fix value of MT_ALL to remove MT_DEBUG. (Bruce Jerrick) * Fix NULL deref in waitproc(). (F.W. ten Wolde) * Define $(MAKE) for those platforms who don't. (Don Beusee) * Add include "filesys.h" to hasmntopt.c to fix compile time error. * Fix NULL deref when no target specified. (Don Beusee) From wls@astro.UMD.EDU Tue Aug 3 06:21:55 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12859; Tue, 3 Aug 93 06:21:55 PDT Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA12597; Tue, 3 Aug 1993 09:21:55 -0400 Date: Tue, 3 Aug 1993 09:21:55 -0400 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199308031321.AA12597@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: lots of static bufs The first thing I noticed when I compiled the new rdist (6.1 beta 2) on a Sparc (SunOS 4.1.2) and compared it to 6.1 beta 1 is the change in size: old: text data bss dec hex 65536 8192 77640 151368 24f48 /usr/ucb/rdist 40960 8192 38440 87592 15628 /usr/ucb/rdistd new: text data bss dec hex 65536 8192 317432 391160 5f7f8 rdist 40960 8192 278064 327216 4fe30 rdistd The bss section has grown by quite a bit. On inpection I noticed that the buffer sizes in src/message.c have changed from various values (mostly 8192 or BUFSIZ, to MSGBUFSIZ which is set equal to 32*1024 = 32768. A fair fraction of the routines in this file have a static buffer size MSGBUFSIZ. Why is it necessary to have all of these different static buffers around. It seems to me that there could be just one of these buffers or at least a smaller number. With a quick inspection of the code I am having trouble seeing why most of these buffers couldn't be dynamic (i.e. auto) rather than static. This has bothered me before but increasing the size of these buffers has made the problem worse, making both rdist and rdistd more heavyweight than necessary. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From wls@astro.UMD.EDU Tue Aug 3 07:29:43 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15224; Tue, 3 Aug 93 07:29:43 PDT Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA13440; Tue, 3 Aug 1993 10:29:43 -0400 Date: Tue, 3 Aug 1993 10:29:43 -0400 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199308031429.AA13440@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: update for multiflow support This I suspect is of interest to practically no one as I don't know who else is still running one of these machines. I missed installing the last rdist release on the multiflow because it was down then. Anyway, here is the change to config/os-tracebsd.h that is needed to get rdist-6.1 beta 2 to compile and run on a Multiflow Trace 7. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu ===Cut Here=== *** os-tracebsd.h.ORIG Wed Jul 14 18:07:40 1993 --- os-tracebsd.h Tue Aug 3 09:55:14 1993 *************** *** 50,55 **** --- 50,60 ---- #endif /* + * OS specific items + */ + typedef int pid_t; + + /* * Set process args to messages that show up when running ps(1) * * Under some OS's, the SETARGS code will cause ": is not an identifier" *************** *** 121,127 **** /* * Generic pointer, used by memcpy, malloc, etc. Usually char or void. */ ! typedef void POINTER; /* * Type of set file time function available --- 126,132 ---- /* * Generic pointer, used by memcpy, malloc, etc. Usually char or void. */ ! typedef char POINTER; /* * Type of set file time function available ===Cut Here=== From mcooper@acamar.usc.edu Tue Aug 3 10:49:04 1993 Return-Path: Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23447; Tue, 3 Aug 93 10:49:04 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA21562; Tue, 3 Aug 93 10:48:48 PDT Sender: "Michael A. Cooper" Date: Tue, 3 Aug 93 10:48:48 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: wls@astro.UMD.EDU (William L. Sebok) Cc: rdist-dev@usc.edu Subject: Re: lots of static bufs In-Reply-To: Your message of Tue, 3 Aug 1993 09:21:55 -0400 Message-Id: Content-Length: 245 This has been on my fix list for a while. Several people reported problems in 6.1beta.? which were due to several of the buffers being to small. My temporary fix was to increase their size. I don't plan on really fixing this until 6.2. mike From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Tue Aug 3 16:43:08 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09299; Tue, 3 Aug 93 16:43:08 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06005; Tue, 3 Aug 93 19:43:07 -0400 Received: from meaddata.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 194109.22500; Tue, 3 Aug 1993 19:41:09 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA02119; Tue, 3 Aug 93 19:22:41 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA03719; Tue, 3 Aug 93 19:22:37 EDT Date: Tue, 3 Aug 93 19:22:37 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9308032322.AA03719@weasel.meaddata.com> To: rdist-dev@usc.edu Subject: local defines in Makefile.local I wanted to use Makefile.local to add some defines that pertain to our site, but didn't want to mess with "DEFS_SYS" because it really has nothing to do with the platform itself. I'm interested in any comments on the approach I used, which involved a trivial (and I believe general) change to src/Makefile.real, shown in the context diff below. I can now include the following in Makefile.local: CLIENT = rdist6 SERVER = rdist6d DEFS_LOCAL = -D_PATH_RDISTD=\"$(SERVER)\" Comments? =-=-=-=-=-=-=-=-=-=-= diff -c src/Makefile.real* =-=-=-=-=-=-=-=-=-=-=-=-= *** src/Makefile.real Tue Aug 3 18:45:57 1993 --- src/Makefile.real-orig Fri Jul 16 17:28:50 1993 *************** *** 48,54 **** SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o OS_H = os-$(OS).h ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) $(DEFS_LOCAL) LIBS = $(LIB_SYS) CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) --- 48,54 ---- SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o OS_H = os-$(OS).h ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) LIBS = $(LIB_SYS) CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Tue Aug 3 16:43:09 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09300; Tue, 3 Aug 93 16:43:09 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06019; Tue, 3 Aug 93 19:43:08 -0400 Received: from meaddata.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 194109.22494; Tue, 3 Aug 1993 19:41:09 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA01937; Tue, 3 Aug 93 19:15:52 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA03692; Tue, 3 Aug 93 19:15:47 EDT Date: Tue, 3 Aug 93 19:15:47 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9308032315.AA03692@weasel.meaddata.com> To: rdist-dev@usc.edu Subject: runmake -- order of -f args I'm just now getting around to compiling the latest version of rdist. First, I'll just say that my hat's off to whomever took the time to split everything into subdirectories and separate platform-specific stuff into individual files. This seems to be an excellent approach. Thanks... What's gone into choosing the order in which make concatenates the various Makefile fragments? I'm finding that certain lines in my "Makefile.local" need to be evaluated before src/Makefile.real, while others need to be evaluated after. For example, "CLIENT=foo" must be evaluated early if we want "CLIENT_BIN" to wind up with the intuitive value, but "LIBS = $(LIB_SYS) otherstuff.a" has to be evaluated late to avoid being trampled. In my case, I was able to modify runmake to actually include the Makefile.local in two different places (see the diff below). I'm not sure this is a good general solution, though. In the broadest sense, I think the problem is that sometimes we want to override things in "mf/Makefile.var", and other times "src/Makefile.real". A single "Makefile.local" may not cut it. Comments? =-=-=-=-=-=-=-=-=-=-= diff -c config/runmake* =-=-=-=-=-=-=-=-=-=-= *** config/runmake Tue Aug 3 18:46:09 1993 --- config/runmake-orig Thu Jul 15 19:30:54 1993 *************** *** 72,80 **** if [ -f ../mf/Makefile.var ]; then MKARGS="${MKARGS} -f ../mf/Makefile.var" fi - if [ -f ../Makefile.local ]; then - MKARGS="${MKARGS} -f ../Makefile.local" - fi if [ -f ../config/mf.${OS} ]; then MKARGS="${MKARGS} -f ../config/mf.${OS}" fi --- 72,77 ---- From dbeusee@us.oracle.com Tue Aug 3 22:41:45 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21564; Tue, 3 Aug 93 22:41:45 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA06646; Tue, 3 Aug 93 22:41:40 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06790; Tue, 3 Aug 93 22:36:35 PDT Message-Id: <9308040536.AA06790@dbeusee.us.oracle.com> Date: Tue, 3 Aug 93 22:36:35 PDT From: Don Beusee To: rdist-dev@usc.edu, todd@meaddata.com Subject: Re: local defines in Makefile.local What about putting site specific stuff in config/config.h ?? From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Tue Aug 3 16:51:34 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA05474; Tue, 3 Aug 93 16:51:33 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA27504; Tue, 3 Aug 93 16:56:33 PDT Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09299; Tue, 3 Aug 93 16:43:08 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06005; Tue, 3 Aug 93 19:43:07 -0400 Received: from meaddata.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 194109.22500; Tue, 3 Aug 1993 19:41:09 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA02119; Tue, 3 Aug 93 19:22:41 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA03719; Tue, 3 Aug 93 19:22:37 EDT Date: Tue, 3 Aug 93 19:22:37 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9308032322.AA03719@weasel.meaddata.com> To: rdist-dev@usc.edu Subject: local defines in Makefile.local Status: R I wanted to use Makefile.local to add some defines that pertain to our site, but didn't want to mess with "DEFS_SYS" because it really has nothing to do with the platform itself. I'm interested in any comments on the approach I used, which involved a trivial (and I believe general) change to src/Makefile.real, shown in the context diff below. I can now include the following in Makefile.local: CLIENT = rdist6 SERVER = rdist6d DEFS_LOCAL = -D_PATH_RDISTD=\"$(SERVER)\" Comments? =-=-=-=-=-=-=-=-=-=-= diff -c src/Makefile.real* =-=-=-=-=-=-=-=-=-=-=-=-= *** src/Makefile.real Tue Aug 3 18:45:57 1993 --- src/Makefile.real-orig Fri Jul 16 17:28:50 1993 *************** *** 48,54 **** SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o OS_H = os-$(OS).h ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) $(DEFS_LOCAL) LIBS = $(LIB_SYS) CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) --- 48,54 ---- SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o OS_H = os-$(OS).h ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) LIBS = $(LIB_SYS) CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) From dbeusee@us.oracle.com Wed Aug 4 04:39:12 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02761; Wed, 4 Aug 93 04:39:12 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA15075; Wed, 4 Aug 93 04:39:11 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07978; Wed, 4 Aug 93 04:34:05 PDT Message-Id: <9308041134.AA07978@dbeusee.us.oracle.com> Date: Wed, 4 Aug 93 04:34:05 PDT From: Don Beusee To: mcooper@usc.edu Subject: Re: patch for parallel rdist Cc: rdist-dev@usc.edu As suspected, this did not fix the bug. The sleep is req'd. From mcooper@acamar.usc.edu Tue Jul 27 16:46:21 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08201; Tue, 27 Jul 93 16:46:19 PDT Received: from usc.edu by gatekeeper.oracle.com (5.59.11/37.7) id AA13911; Tue, 27 Jul 93 16:51:22 PDT Received: from acamar.usc.edu.ucs by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25227; Tue, 27 Jul 93 16:31:42 PDT Received: by acamar.usc.edu.ucs (5.0/SMI-SVR4) id AA19734; Tue, 27 Jul 93 16:31:32 PDT Sender: "Michael A. Cooper" Date: Tue, 27 Jul 93 16:31:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: patch for parallel rdist In-Reply-To: Your message of Sat, 24 Jul 93 12:12:57 PDT Message-Id: Content-Length: 2165 Status: RO I still don't like just putting a sleep() call in. I did find some casting problems that could mask an error from fork(). Please apply the patch below _without_ the sleep() call and let me know if the problem still persists. mike *** /tmp/T0a004o2 Tue Jul 27 16:29:10 1993 --- /tmp/T1a004o2 Tue Jul 27 16:29:10 1993 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.18 1993/07/15 22:48:58 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: child.c,v 6.19 1993/07/27 23:27:44 mcooper Exp $"; static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; *************** *** 65,71 **** struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! int c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; --- 65,71 ---- struct _child { char *c_name; /* Name of child */ int c_readfd; /* Read file descriptor */ ! pid_t c_pid; /* Process ID */ PROCSTATE c_state; /* Running? */ struct _child *c_next; /* Next entry */ }; *************** *** 274,280 **** static void reap() { register CHILD *pc; ! int status = 0, pid; debugmsg(DM_CALL, "reap() called\n"); --- 274,281 ---- static void reap() { register CHILD *pc; ! int status = 0; ! pid_t pid; debugmsg(DM_CALL, "reap() called\n"); *************** *** 459,465 **** struct cmd *cmd; struct cmd *cmdlist; { ! int pid; int fildes[2]; char *childname = cmd->c_name; --- 460,466 ---- struct cmd *cmd; struct cmd *cmdlist; { ! pid_t pid; int fildes[2]; char *childname = cmd->c_name; *************** *** 469,475 **** } pid = fork(); ! if (pid == -1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); --- 470,476 ---- } pid = fork(); ! if (pid == (pid_t)-1) { error("Cannot spawn child for %s: fork failed: %s", childname, SYSERR); return(-1); From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Wed Aug 4 09:43:14 1993 Return-Path: Received: from relay2.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12998; Wed, 4 Aug 93 09:43:14 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10594; Wed, 4 Aug 93 12:43:11 -0400 Received: from meaddata.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 124153.25657; Wed, 4 Aug 1993 12:41:53 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA11055; Wed, 4 Aug 93 12:22:33 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA05715; Wed, 4 Aug 93 12:22:30 EDT Date: Wed, 4 Aug 93 12:22:30 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9308041622.AA05715@weasel.meaddata.com> To: dbeusee@us.oracle.com Subject: Re: local defines in Makefile.local Cc: rdist-dev@usc.edu Definitely an option -- I preferred using Makefile.local, however, to avoid adding a file that I'd need to patch with each new distribution of rdist. For maintenance, there's something very elegant about having a single place to look for "local stuff". not mixed in with the official stuff being maintained elsewhere... > From dbeusee@us.oracle.com Wed Aug 4 03:18:23 1993 > Date: Tue, 3 Aug 93 22:36:35 PDT > From: Don Beusee > To: rdist-dev@usc.edu, todd@meaddata.com > Subject: Re: local defines in Makefile.local > > What about putting site specific stuff in config/config.h ?? > > >From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Tue Aug 3 16:51:34 1993 > Date: Tue, 3 Aug 93 19:22:37 EDT > From: todd@meaddata.com (Todd Leonard) > To: rdist-dev@usc.edu > Subject: local defines in Makefile.local > > I wanted to use Makefile.local to add some defines that pertain to > our site, but didn't want to mess with "DEFS_SYS" because it really > has nothing to do with the platform itself. I'm interested in any > comments on the approach I used, which involved a trivial (and I > believe general) change to src/Makefile.real, shown in the context > diff below. I can now include the following in Makefile.local: > > CLIENT = rdist6 > SERVER = rdist6d > DEFS_LOCAL = -D_PATH_RDISTD=\"$(SERVER)\" > > Comments? > > > > =-=-=-=-=-=-=-=-=-=-= diff -c src/Makefile.real* =-=-=-=-=-=-=-=-=-=-=-=-= > > *** src/Makefile.real Tue Aug 3 18:45:57 1993 > --- src/Makefile.real-orig Fri Jul 16 17:28:50 1993 > *************** > *** 48,54 **** > SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o > > OS_H = os-$(OS).h > ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) $(DEFS_LOCAL) > LIBS = $(LIB_SYS) > CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) > > --- 48,54 ---- > SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o > > OS_H = os-$(OS).h > ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) > LIBS = $(LIB_SYS) > CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) From dbeusee@us.oracle.com Wed Aug 4 15:23:13 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28884; Wed, 4 Aug 93 15:23:13 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7) id AA20653; Wed, 4 Aug 93 15:23:04 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10031; Wed, 4 Aug 93 15:17:58 PDT Message-Id: <9308042217.AA10031@dbeusee.us.oracle.com> Date: Wed, 4 Aug 93 15:17:58 PDT From: Don Beusee To: todd@meaddata.com Subject: Re: local defines in Makefile.local Cc: rdist-dev@usc.edu But you will need to patch Makefile.local each time too, right? We need a file that is ONLY for local defines. From meaddata!meaddata.com!todd@uunet.UU.NET Wed Aug 4 09:42:12 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09216; Wed, 4 Aug 93 09:42:11 PDT Received: from relay2.UU.NET by gatekeeper.oracle.com (5.59.11/37.7) id AA27628; Wed, 4 Aug 93 09:47:12 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10594; Wed, 4 Aug 93 12:43:11 -0400 Received: from meaddata.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 124153.25657; Wed, 4 Aug 1993 12:41:53 EDT Received: from weasel.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA11055; Wed, 4 Aug 93 12:22:33 EDT Received: by weasel.meaddata.com (4.1/SMI-4.1) id AA05715; Wed, 4 Aug 93 12:22:30 EDT Date: Wed, 4 Aug 93 12:22:30 EDT From: todd@meaddata.com (Todd Leonard) Message-Id: <9308041622.AA05715@weasel.meaddata.com> To: dbeusee@us Subject: Re: local defines in Makefile.local Cc: rdist-dev@usc.edu Status: R Definitely an option -- I preferred using Makefile.local, however, to avoid adding a file that I'd need to patch with each new distribution of rdist. For maintenance, there's something very elegant about having a single place to look for "local stuff". not mixed in with the official stuff being maintained elsewhere... > From dbeusee@us.oracle.com Wed Aug 4 03:18:23 1993 > Date: Tue, 3 Aug 93 22:36:35 PDT > From: Don Beusee > To: rdist-dev@usc.edu, todd@meaddata.com > Subject: Re: local defines in Makefile.local > > What about putting site specific stuff in config/config.h ?? > > >From todd%meaddata.com%meaddata.uucp@uunet.UU.NET Tue Aug 3 16:51:34 1993 > Date: Tue, 3 Aug 93 19:22:37 EDT > From: todd@meaddata.com (Todd Leonard) > To: rdist-dev@usc.edu > Subject: local defines in Makefile.local > > I wanted to use Makefile.local to add some defines that pertain to > our site, but didn't want to mess with "DEFS_SYS" because it really > has nothing to do with the platform itself. I'm interested in any > comments on the approach I used, which involved a trivial (and I > believe general) change to src/Makefile.real, shown in the context > diff below. I can now include the following in Makefile.local: > > CLIENT = rdist6 > SERVER = rdist6d > DEFS_LOCAL = -D_PATH_RDISTD=\"$(SERVER)\" > > Comments? > > > > =-=-=-=-=-=-=-=-=-=-= diff -c src/Makefile.real* =-=-=-=-=-=-=-=-=-=-=-=-= > > *** src/Makefile.real Tue Aug 3 18:45:57 1993 > --- src/Makefile.real-orig Fri Jul 16 17:28:50 1993 > *************** > *** 48,54 **** > SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o > > OS_H = os-$(OS).h > ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) $(DEFS_LOCAL) > LIBS = $(LIB_SYS) > CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) > > --- 48,54 ---- > SERVEROBJS = $(O)rdistd.o $(O)server.o $(O)filesys.o $(O)filesys-os.o > > OS_H = os-$(OS).h > ! DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) > LIBS = $(LIB_SYS) > CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) From stevea@lachman.com Fri Aug 20 14:09:37 1993 Return-Path: Received: from laidbak.i88.isc.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23462; Fri, 20 Aug 93 14:09:37 PDT Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP (5.65/isc-mail-gw/2/23/93) id AA03949; Fri, 20 Aug 93 16:09:29 -0500 Received: from westend.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1) id AA13487; Fri, 20 Aug 93 16:09:28 CDT Message-Id: <9308202109.AA13487@ra.i88.isc.com> To: rdist-dev@usc.edu Subject: call to msgparseopts in rdistd.c Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Aug 1993 16:09:26 -0500 From: Steve Alexander Hi -- Perhaps I am confused, but it seems as though the call to msgparseopts in rdistd.c is missing the second argument. Presumably the second argument should be TRUE? Thanks, -- Steve From sources@elliot.ICS.UCI.EDU Fri Aug 20 15:34:23 1993 Return-Path: Received: from ics.uci.edu (paris.ics.uci.edu) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26632; Fri, 20 Aug 93 15:34:23 PDT Received: from elliot.ics.uci.edu by Paris.ics.uci.edu id aa18370; 20 Aug 93 15:28 PDT To: rdist-dev@usc.EDU Subject: patch to use NIS netgroups Date: Fri, 20 Aug 1993 15:29:30 -0700 From: Scott Erickson Message-Id: <9308201528.aa18370@Paris.ics.uci.edu> Base version: Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 Description: Enable NIS netgroup expansion. If a "host" target starts with a '@', then the rest of the "host" is expanded as a NIS netgroup. % rdist -c .cshrc @sun_hosts or FILES = ( /home/sources/.cshrc ) HOSTS = ( @sun_hosts ) ${FILES} -> ${HOSTS} install; We added this to our old Berkeley rdist, and it was trivial to add it to version 6.1beta.2. Compiling: To enable NIS netgroup expansion, add the following line to your Makefile.local file: NETGROUPS = -DUSE_NETGROUPS Also, add the patches below. /se *** /tmp/T0a000IS Fri Aug 20 15:09:37 1993 --- ./include/defs.h Fri Aug 20 15:03:02 1993 *************** *** 34,40 **** */ /* ! * $Id: defs.h,v 6.62 1993/07/16 21:33:03 mcooper Exp $ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ --- 34,40 ---- */ /* ! * $Id: defs.h,v 6.63 1993/08/20 22:03:17 sources Exp $ * @(#)defs.h 5.2 (Berkeley) 3/20/86 */ *************** *** 128,134 **** --- 128,139 ---- #define E_VARS 0x1 #define E_SHELL 0x2 #define E_TILDE 0x4 + #ifdef USE_NETGROUPS + #define E_NETG 0x8 + #define E_ALL 0xf + #else #define E_ALL 0x7 + #endif /* actions for lookup() */ #define LOOKUP 0 *** /tmp/T0a000IV Fri Aug 20 15:09:37 1993 --- ./src/Makefile.real Fri Aug 20 15:04:08 1993 *************** *** 31,37 **** # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # ! # $Id: Makefile.real,v 1.5 1993/07/16 21:28:43 mcooper Exp $ # IN_ARGS = -c -g ${BIN_GROUP} --- 31,37 ---- # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # ! # $Id: Makefile.real,v 1.6 1993/08/20 22:04:39 sources Exp $ # IN_ARGS = -c -g ${BIN_GROUP} *************** *** 50,56 **** OS_H = os-$(OS).h DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) LIBS = $(LIB_SYS) ! CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) INCLUDE = -I. -I../include -I../config $(OTHERINCS) $(INCLUDE_SYS) --- 50,56 ---- OS_H = os-$(OS).h DEFS = -DOS_H=\"$(OS_H)\" $(DEFS_SYS) LIBS = $(LIB_SYS) ! CFLAGS = $(OPT) $(DEFS) $(INCLUDE) $(CFLAGS_OS) $(NETGROUPS) INCLUDE = -I. -I../include -I../config $(OTHERINCS) $(INCLUDE_SYS) *** /tmp/T0a000IY Fri Aug 20 15:09:38 1993 --- ./src/expand.c Fri Aug 20 15:06:03 1993 *************** *** 33,39 **** #ifndef lint static char RCSid[] = ! "$Id: expand.c,v 6.10 1992/11/10 01:55:20 mcooper Exp $"; static char sccsid[] = "@(#)expand.c 5.2 (Berkeley) 3/28/86"; --- 33,39 ---- #ifndef lint static char RCSid[] = ! "$Id: expand.c,v 6.11 1993/08/20 22:06:35 sources Exp $"; static char sccsid[] = "@(#)expand.c 5.2 (Berkeley) 3/28/86"; *************** *** 223,228 **** --- 223,253 ---- sort(); return; } + #ifdef USE_NETGROUPS + /* + * If looking for netgroups, look for an @ in the hostname. Set + * cp to the @ right before the netgroup name. If @ is at the + * beginning of the name, then the rest is a netgroup name, otherwise + * search for user@@netgroup. + */ + if ((which & E_NETG) && ((cp = strchr(s, '@')) && + (cp == s || (cp = strchr(cp+1, '@'))))) + { + char *hname, *junk; + + /* Cp points at the @ before the netgroup name */ + + *cp++ = '\0'; + setnetgrent(cp); + while (getnetgrent(&hname, &junk, &junk)) { + if (hname && *hname) { + Cat(s, hname); + } + } + endnetgrent(); + return; + } + #endif /* USE_NETGROUPS */ if (*s == '~') { cp = ++s; if (*cp == CNULL || *cp == '/') { From karl%owl.HQ.Ileaf.COM%leafusa.uucp@uunet.UU.NET Mon Aug 23 01:46:42 1993 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15018; Mon, 23 Aug 93 01:46:42 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17855; Mon, 23 Aug 93 01:06:05 -0400 Received: from leafusa.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 010456.14158; Mon, 23 Aug 1993 01:04:56 EDT Received: from owl.HQ.Ileaf.COM by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for rdist-dev@usc.edu id AA23343; Sun, 22 Aug 93 10:55:07 EDT Received: by owl.HQ.Ileaf.COM (4.1/SMI-4.0-hq) for rdist-dev@usc.edu id AA18785; Sun, 22 Aug 93 10:54:48 EDT Date: Sun, 22 Aug 93 10:54:48 EDT From: karl@owl.HQ.Ileaf.COM (Karl Berry) Message-Id: <9308221454.AA18785@owl.HQ.Ileaf.COM> To: rdist-dev@usc.edu Subject: rdist 6.1.2 compile fails on hp300 Reply-To: karl@HQ.Ileaf.COM On an hp300 running hpux 7, compiling with cc, rdist 6.1.2 doesn't compile as-is: isexec.c tries to use the header for hp700's, which naturally doesn't work too well. I did the simplest thing and turned off the exec checking: *** ./ORIG/os-hpux.h Wed Jul 14 18:39:16 1993 --- ./os-hpux.h Sun Aug 22 09:53:54 1993 *************** *** 91,95 **** --- 91,97 ---- * Select the type of executable file format. */ + #ifndef __hp9000s300 #define EXE_TYPE EXE_HPEXEC + #endif /* Also on the hp300, `MOUNTED' is not defined. Without this, filesys.c doesn't compile. *** ./ORIG/filesys.h Fri Jul 16 17:33:41 1993 --- ./filesys.h Sun Aug 22 10:07:10 1993 *************** *** 64,68 **** #if FSI_TYPE == FSI_GETMNTENT # include ! # define MOUNTED_FILE MOUNTED #endif #if FSI_TYPE == FSI_GETMNTENT2 --- 64,72 ---- #if FSI_TYPE == FSI_GETMNTENT # include ! #ifdef __hp9000s300 ! # define MOUNTED_FILE "" ! #else ! # define MOUNTED_FILE MOUNTED ! #endif #endif #if FSI_TYPE == FSI_GETMNTENT2 From fred@cv.ruu.nl Mon Aug 23 07:40:56 1993 Return-Path: Received: from prisma.cv.ruu.nl by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25871; Mon, 23 Aug 93 07:40:56 PDT Received: from triton (triton.cv.ruu.nl) by prisma.cv.ruu.nl with SMTP id AA03015 (5.65c/IDA-1.4.4); Mon, 23 Aug 1993 16:39:45 +0200 Received: by triton id AA00029 (5.65c/IDA-1.4.4); Mon, 23 Aug 1993 16:39:45 +0200 From: Fred Appelman Message-Id: <199308231439.AA00029@triton> Subject: Re: rdist 6.1.2 compile fails on hp300 To: karl@hq.ileaf.com Date: Mon, 23 Aug 1993 16:39:44 +0100 (METDST) Cc: rdist-dev@usc.edu In-Reply-To: <9308221454.AA18785@owl.HQ.Ileaf.COM> from "Karl Berry" at Aug 22, 93 10:54:48 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1388 > > On an hp300 running hpux 7, compiling with cc, rdist 6.1.2 doesn't > compile as-is: isexec.c tries to use the header for hp700's, which > naturally doesn't work too well. I did the simplest thing and turned > off the exec checking: > > *** ./ORIG/os-hpux.h Wed Jul 14 18:39:16 1993 > --- ./os-hpux.h Sun Aug 22 09:53:54 1993 > *************** > *** 91,95 **** > --- 91,97 ---- > * Select the type of executable file format. > */ > + #ifndef __hp9000s300 > #define EXE_TYPE EXE_HPEXEC > + #endif > > /* > I applied the following patch to get the isexec working on the 300 series. (Don't install them both) Fred -- Fred J.R. Appelman, 3D Computer Vision, Utrecht University AZU, Heidelberglaan 100, 3584 CX Utrecht, The Netherlands. Telephone: +31-30-506710 Fax: +31-30-513399 e-mail: fred@cv.ruu.nl or appelman@cs.unc.edu *** rdist-org/src/isexec.c Fri Jul 16 00:25:28 1993 --- rdist/src/isexec.c Thu Aug 12 15:19:55 1993 *************** *** 183,190 **** --- 183,196 ---- * HP 9000/[78]00 executable format */ + #ifdef hp9000s300 + #include + #define header exec + #define ISEXEC(a) ((a.file_type)==EXEC_MAGIC || (a.file_type)==SHARE_MAGIC || (a.file_type)==DEMAND_MAGIC) + #else #define ISEXEC(a) ((a)==EXEC_MAGIC || (a)==SHARE_MAGIC || (a)==DEMAND_MAGIC) #include + #endif static int _isexec(fd) int fd; From marc@Synergytics.Com Fri Sep 3 11:42:54 1993 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04539; Fri, 3 Sep 93 11:42:54 PDT Received: by synergy.Synergytics.Com; id AA06375; Fri, 3 Sep 1993 14:44:43 -0400 Received: from localhost by synergy.Synergytics.Com; (5.65/1.1.3.9/15Apr93-0824AM) id AA06375; Fri, 3 Sep 1993 14:44:43 -0400 Message-Id: <9309031844.AA06375@synergy.Synergytics.Com> Reply-To: Marc@Synergytics.Com To: rdist-dev@usc.edu Cc: ajr@synergy.Synergytics.Com, terryh@unixhub.slac.stanford.edu, pfkeb@ebnextk.slac.stanford.edu Subject: Building 6.1beta2 on Dell SVR4.0 Date: Fri, 03 Sep 93 14:44:42 +0100 From: Marc Evans - Contract Software Hacker X-Mts: smtp Hi - I sent a message earlier today indicating problems I was having with getting rdist to function as I expected on Dell SVR4.0. Well, I believe that I have now succeeded in my quest, though I have a bad feeling that the route I have taken is not a good one. I have attached a set of context diffs for what I changed, as well as a verbal list of the problems I believe I have encountered and an attempt of an explaination. Here is the short list of issues: 1- SVR4.0 does not source in ~/.{profile,cshrc,login,kshrc} via rsh. 2- setreuid() does not behave as expected. 3- both rdist and rdistd require root privs. Item 1 is the stimulus for me changing the invocation paths to be absolute (such as _PATH_RDISTD). Unlike BSD derived systems which source in certain dot files when a shell is invoked via rsh, SVR4 does NOT appear to do the same. Therefore, if you install rdist or rdistd in a path other then what is known about by default to the shell. Item 2 is an interresting issue. It would appear that on SVR4 systems you get one chance to setreuid()/setuid() if you are changing to somethign other then root. Therefore, I have added the #if's that make this only happen once (blindly without concern for security!). Have I now left myself open to security issues? Item 3 is required if you plan to have non-root user use rdist and be able to succeed at the syscalls to chown/fchown. If rdistd is not installed SUID=root and a non-root user is the invoker (which is the case within rcvs), those syscalls will fail because only the superuser is permitted to do chown's. Again, am I leaving myself open to a security issue by doing this? Something I am having a hard time understanding is that it appears that this has been ported to SOLARIS 2.* which is SVR4 based. Did users on this OS experience similiar problems as I have? Happy hacking - Marc diff -rc rdist/Makefile.local rdist.mod/Makefile.local *** rdist/Makefile.local Fri Feb 19 21:21:50 1993 --- rdist.mod/Makefile.local Fri Sep 3 10:49:16 1993 *************** *** 8,11 **** # BIN_DIR variable, you would uncomment the following line # or add your own line. # ! #BIN_DIR = /usr/bin --- 8,26 ---- # BIN_DIR variable, you would uncomment the following line # or add your own line. # ! BIN_DIR = /usr/local/bin ! BIN_OWNER = bin ! BIN_GROUP = bin ! BIN_MODE = 755 ! MAN_1_DIR = /usr/local/man/man1 ! MAN_8_DIR = /usr/local/man/man8 ! MAN_1_SECT = 1 ! MAN_8_SECT = 8 ! MAN_OWNER = bin ! MAN_GROUP = bin ! MAN_MODE = 644 ! INSTALL = /usr/ucb/install ! CC = /usr/bin/cc -DSVR4 ! RANLIB = true ! LIBS = -lsocket -lnsl -lucb -L/usr/ccs/lib -lc ! MISSINGOBJS = hasmntopt.o diff -rc rdist/config/config.h rdist.mod/config/config.h *** rdist/config/config.h Wed Jan 6 22:10:47 1993 --- rdist.mod/config/config.h Thu Sep 2 12:49:55 1993 *************** *** 64,71 **** # the "#define" line. If you don't want to be backwards compability or * don't have the old rdist, then uncomment the "#undef" line. */ ! #define _PATH_OLDRDIST "/usr/ucb/oldrdist" /* Enable compat */ ! /*#undef _PATH_OLDRDIST /* Disable compat */ /* * Check to see if file is on a NFS. If it is, the file is --- 64,71 ---- # the "#define" line. If you don't want to be backwards compability or * don't have the old rdist, then uncomment the "#undef" line. */ ! /*#define _PATH_OLDRDIST "/usr/ucb/oldrdist" /* Enable compat */ ! #undef _PATH_OLDRDIST /* Disable compat */ /* * Check to see if file is on a NFS. If it is, the file is diff -rc rdist/include/pathnames.h rdist.mod/include/pathnames.h *** rdist/include/pathnames.h Tue Jan 5 16:28:33 1993 --- rdist.mod/include/pathnames.h Thu Sep 2 16:15:59 1993 *************** *** 43,47 **** #endif /* _RDIST_TMP */ #if !defined(_PATH_RDISTD) ! # define _PATH_RDISTD "rdistd" /* Rdist server */ #endif /* _PATH_RDISTD */ --- 43,47 ---- #endif /* _RDIST_TMP */ #if !defined(_PATH_RDISTD) ! # define _PATH_RDISTD "/usr/local/bin/rdistd" /* Rdist server */ #endif /* _PATH_RDISTD */ diff -rc rdist/src/common.c rdist.mod/src/common.c *** rdist/src/common.c Thu Jul 15 18:23:33 1993 --- rdist.mod/src/common.c Fri Sep 3 11:28:53 1993 *************** *** 642,648 **** --- 642,652 ---- { int r; + #if !defined(SVR4) r = setreuid(ruid, euid); + #else + r = setuid(getuid()); + #endif if (r < 0) error("setreuid(%d, %d) failed: %s (ruid = %d euid = %d)", ruid, euid, SYSERR, getuid(), geteuid()); diff -rc rdist/src/docmd.c rdist.mod/src/docmd.c *** rdist/src/docmd.c Fri Jul 16 17:17:33 1993 --- rdist.mod/src/docmd.c Fri Sep 3 11:29:05 1993 *************** *** 295,302 **** --- 295,304 ---- (void) fflush(stdout); (void) fflush(stderr); + #if !defined(SVR4) if (dosetreuid(userid, 0) != 0) exit(1); + #endif (void) signal(SIGALRM, sighandler); (void) alarm(RTIMEOUT); rem = rcmd(&rhost, port, locuser, ruser, buf, 0); diff -rc rdist/src/rdist.c rdist.mod/src/rdist.c *** rdist/src/rdist.c Wed Jul 28 21:01:00 1993 --- rdist.mod/src/rdist.c Fri Sep 3 11:29:34 1993 *************** *** 111,118 **** --- 111,120 ---- exit(1); } + #if !defined(SVR4) if (dosetreuid(0, userid) != 0) exit(1); + #endif while ((c = getopt(argc, argv, optchars)) != -1) switch (c) { =========================================================================== Marc Evans - Marc@Synergytics.COM | Synergytics (603)635-8876 WB1GRH - WB1GRH@W2XO.#WPA.PA.USA.NOAM | 21 Hinds Ln, Pelham, NH 03076 --------------------------------------------------------------------------- Unix and X11 Software Consultant =========================================================================== From mitra@pandora.sf.ca.us Sat Sep 18 15:09:26 1993 Return-Path: Received: from pandora.sf.ca.us by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25655; Sat, 18 Sep 93 15:09:26 PDT From: mitra@path.net (Mitra) Date: Sat, 18 Sep 1993 15:09:24 PDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: rdist-dev@usc.edu Subject: Porting to SCO Unix and FSI_TYPE Message-Id: <9309181509.aa01352@pandora.sf.ca.us> Hi I'm trying to port rdist to SCO Unix, most of the porting is progressing smoothly, thanks in part to hte number of other systems its been ported to but..... I'm trying to figure out which type to use for FSI_TYPE, none of them compile correctly, either cos of missing include files, or because of things not defined in the include files I have. I'm prepared to hack code but some guidelines on which to use would be usefull. Notes in the TEMPLATE or def files would be even more usefull, there has been a lot of guesswork in this process, not helped by many of the stuff in os-* files not being in hte TEMPLATE. - Mitra P.S. I've only just subscribed to the list, and it hasnt started coming back to me yet, so please Cc me on any reply at "mitra@path.net" From stevea@lachman.com Sat Sep 18 15:52:18 1993 Return-Path: Received: from laidbak.i88.isc.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26928; Sat, 18 Sep 93 15:52:18 PDT Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP (5.65/isc-mail-gw/2/23/93) id AA17211; Sat, 18 Sep 93 17:50:42 -0500 Received: from ozzy.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1) id AA05986; Sat, 18 Sep 93 17:52:11 CDT Message-Id: <9309182252.AA05986@ra.i88.isc.com> To: mitra@path.net (Mitra) Cc: rdist-dev@usc.edu Subject: Re: Porting to SCO Unix and FSI_TYPE In-Reply-To: Message from mitra@path.net of 18 Sep 1993 15:09:24 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Sep 1993 17:52:10 -0500 From: Steve Alexander mitra@path.net (Mitra) writes: > >I'm trying to figure out which type to use for FSI_TYPE, none of >them compile correctly, either cos of missing include files, or >because of things not defined in the include files I have. You will pretty much have to roll your own, as SCO has no standard API for this (at least not one that you can get easily). There is a libmnt that parses /etc/mnttab, but I don't believe that it is part of any development system that you can buy. In any event, it doesn't really do much more than just return structures that you have to crack yourself. You may be able to get libmnt from SCO if you call up and yell at them, but it's really not worth it. For what rdist needs, use the mnttab structure defined in /usr/include/mnttab.h. File system read-only status can be determined by looking at mt_ro_flg, (non-zero == RO), and a ':' character in mt_dev means that this is an NFS file system (disgusting, I know). I don't think that rdist needs any more support than that at this time. When I ported rdist, I used libmnt, so I'm afraid that I don't have any code that I can send you. Good luck, -- Steve From tito@di.unipi.it Tue Sep 28 04:07:02 1993 Return-Path: Received: from apollo.di.unipi.it by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25902; Tue, 28 Sep 93 04:07:02 PDT Message-Id: <9309281107.AA25902@usc.edu> Received: from olimpo.di.unipi.it by apollo.di.unipi.it with SMTP (16.7/16.2) id AA10171; Tue, 28 Sep 93 13:08:00 +0100 Date: Tue, 28 Sep 93 13:08:00 +0100 From: Tito Flagella Received: by olimpo (4.1/SMI-4.1) id AA09497; Tue, 28 Sep 93 12:04:33 +0100 To: rdist-dev@usc.edu In-Reply-To: <199302181953.AA17617@lynx.astro.umd.edu> (wls@astro.UMD.EDU) Subject: Watcher This message is not about rdist, but it should be of general interest. Recently I have adopted a tool named Watcher, by Kenneth Ingham at the University of New Mexico. It is a great tool to monitor the Operating Systems on a large etherogeneous network. The main idea is to allow the user to specify what and how to monitor for, instead of providing a predefined set of features. This allows great flexibility and portability. The Watcher sources available on the network seems to be the first ones released. In the file Ideas there are some reports from Michael Cooper. For this reason I thougth that pheraps some people on this mailing list could have used the tool. Has anybody aware of a more recent release of Watcher? Has anybody reworked the tool. What tools are you using to monitor things like: Critical Processes Disk Space Swap Space CPU time on hundreds of etherogeneous machines. Bye, Tito Flagella. From mcooper@ucs.usc.edu Tue Sep 28 09:58:19 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09176; Tue, 28 Sep 93 09:58:19 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA09080; Tue, 28 Sep 93 09:58:14 PDT Sender: "Michael A. Cooper" Date: Tue, 28 Sep 93 9:58:14 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Tito Flagella Cc: rdist-dev@usc.edu Subject: Re: Watcher In-Reply-To: Your message of Tue, 28 Sep 93 13:08:00 +0100 Message-Id: Content-Length: 189 While it may be true that I did work on Watcher a bit several years ago, it's probably not appropriate to discuss things not related to Rdist on the Rdist Developer's list. Thanks! mike From pfps@research.att.com Wed Sep 29 06:12:29 1993 Return-Path: Received: from research.att.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24600; Wed, 29 Sep 93 06:12:29 PDT Received: by inet; Wed Sep 29 09:10 EDT 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 29 Sep 93 09:11 EDT Received: by idefix.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 29 Sep 93 09:11 EDT Message-Id: Date: Wed, 29 Sep 93 09:11 EDT From: pfps@research.att.com (Peter F. Patel-Schneider) To: rdist-dev@usc.edu Subject: new option to rdist to specify path for rdistd On SVR4 systems, c-shells started via rcmd don't seem to be login shells, and thus don't get a full user environment. This makes it hard to find rdistd. I have thus added a -p option to rdist to specify the command name for rdistd. This allows rdistd to be placed in locations that are not in the system default (for SVR4 systems) or user's (for some other types of systems) path. Any comments on this change? I personally don't like extra options, but I don't see a way around this. If someone else has a workaround, please let me know. Peter F. Patel-Schneider AT&T Bell Labs; 600 Mountain Avenue, 2C-405; Murray Hill, NJ 07974; U.S.A. pfps@research.att.com Here are some examples of this option in action: getafix 158> rdist -w -R -p /opt/rdistd -c . getafix:/tmp/pfps getafix: updating host getafix getafix: LOCAL ERROR: Unexpected input at startup: "/opt/rdistd: Command not found". getafix 161> rdist -w -R -p /opt/bin/rdistd -c . getafix:/tmp/pfps getafix: updating host getafix getafix: ./src/docmd.c: updating getafix: updating of getafix finished Here are the context diffs for the doc and src directories for this option. diff -cr doc.orig/rdist.man doc/rdist.man *** doc.orig/rdist.man Tue Sep 28 20:30:52 1993 --- doc/rdist.man Tue Sep 28 19:55:16 1993 *************** *** 81,86 **** --- 81,90 ---- .B \-t .I timeout ] + [ + .B \-p + .I + ] [ .I name ... ] *************** *** 176,182 **** .fi on each target host. .I Rdist ! does not specify the absolute pathname to .I rdistd on the target host in order to avoid imposing any policy on where .I rdistd --- 180,186 ---- .fi on each target host. .I Rdist ! can specify the pathname to .I rdistd on the target host in order to avoid imposing any policy on where .I rdistd *************** *** 387,392 **** --- 391,399 ---- .I rdist server. The default is 900 seconds. + .TP + .B "\-p \fI\fR" + Set the path where the rdistd server is searched for on the target host. .TP .B \-V Print version information and exit. diff -cr src.bugfix/docmd.c src/docmd.c *** src.bugfix/docmd.c Tue Sep 28 19:00:00 1993 --- src/docmd.c Tue Sep 28 20:00:41 1993 *************** *** 60,65 **** --- 60,66 ---- extern int activechildren; extern int maxchildren; extern int amchild; + extern char *path_rdistd; static void cmptime(); *************** *** 278,284 **** if (!IS_ON(options, DO_QUIET)) message(MT_INFO, "updating host %s", rhost); ! (void) sprintf(buf, "%s -S", _PATH_RDISTD); if (port < 0) { struct servent *sp; --- 279,285 ---- if (!IS_ON(options, DO_QUIET)) message(MT_INFO, "updating host %s", rhost); ! (void) sprintf(buf, "%.*s -S", BUFSIZ-5,path_rdistd); if (port < 0) { struct servent *sp; diff -cr src.bugfix/rdist.c src/rdist.c *** src.bugfix/rdist.c Tue Sep 28 19:00:01 1993 --- src/rdist.c Tue Sep 28 19:25:10 1993 *************** *** 62,69 **** struct group *gr = NULL; /* Static area for getgrent */ char localmsglist[] = "stdout=all:notify=all:syslog=nerror,ferror"; char *remotemsglist = NULL; ! char optchars[] = "A:a:bcd:DFf:hil:L:M:m:NnOo:qRrst:Vvwxy"; FILE *opendist(); main(argc, argv, envp) int argc; --- 62,70 ---- struct group *gr = NULL; /* Static area for getgrent */ char localmsglist[] = "stdout=all:notify=all:syslog=nerror,ferror"; char *remotemsglist = NULL; ! char optchars[] = "A:a:bcd:DFf:hil:L:M:m:NnOo:p:qRrst:Vvwxy"; FILE *opendist(); + char *path_rdistd = _PATH_RDISTD; main(argc, argv, envp) int argc; *************** *** 193,198 **** --- 194,206 ---- optarg); usage(); } + break; + + case 'p': + + path_rdistd = strdup(optarg); + if ( path_rdistd == NULL ) + fatal("Cannot duplicate path to rdistd"); break; /* From pfps@research.att.com Wed Sep 29 06:18:00 1993 Return-Path: Received: from research.att.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24741; Wed, 29 Sep 93 06:18:00 PDT Received: by inet; Wed Sep 29 09:13 EDT 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 29 Sep 93 09:14 EDT Received: by idefix.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 29 Sep 93 09:14 EDT Message-Id: Date: Wed, 29 Sep 93 09:14 EDT From: pfps@research.att.com (Peter F. Patel-Schneider) To: rdist-dev@usc.edu Subject: non-setuid rdist, local distribution Does anyone have any idea on how to make a non-setuid rdist? I was toying with the idea of using rsh as an intermediary, but this would be less efficient. On a related note, I'm using rdist for local distribution, so I don't really need to do the rpc stuff. Has anyone tried to create a fast equivalent rdist for this purpose? Would it be faster to just fork off a child process for local hosts, instead of doing the rpc stuff? Peter F. Patel-Schneider AT&T Bell Labs; 600 Mountain Avenue, 2C-405; Murray Hill, NJ 07974; U.S.A. pfps@research.att.com From dbeusee@us.oracle.com Wed Sep 29 06:57:33 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26273; Wed, 29 Sep 93 06:57:33 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA17602; Wed, 29 Sep 93 06:57:25 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20388; Wed, 29 Sep 93 06:52:40 PDT Message-Id: <9309291352.AA20388@dbeusee.us.oracle.com> Date: Wed, 29 Sep 93 06:52:40 PDT From: Don Beusee To: pfps@research.att.com, rdist-dev@usc.edu Subject: Re: new option to rdist to specify path for rdistd What I do is specify a full path to rdistd in include/pathnames.h: old: # define _PATH_RDISTD "rdistd" /* Rdist server */ new: # define _PATH_RDISTD "/usr/local/bin/rdistd" /* Rdist server */ This way, rdist works consistently regardless what the environment is like on the remote system. The only other alternative, which I don't like, is to have remote:/.cshrc alter the path to include where rdistd is located. Regards, Don. From pfps@research.att.com Wed Sep 29 06:39:09 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20217; Wed, 29 Sep 93 06:38:34 PDT Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA17252; Wed, 29 Sep 93 06:43:07 PDT Received: from research.att.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24600; Wed, 29 Sep 93 06:12:29 PDT Received: by inet; Wed Sep 29 09:10 EDT 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 29 Sep 93 09:11 EDT Received: by idefix.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 29 Sep 93 09:11 EDT Message-Id: Date: Wed, 29 Sep 93 09:11 EDT From: pfps@research.att.com (Peter F. Patel-Schneider) To: rdist-dev@usc.edu Subject: new option to rdist to specify path for rdistd Status: R On SVR4 systems, c-shells started via rcmd don't seem to be login shells, and thus don't get a full user environment. This makes it hard to find rdistd. I have thus added a -p option to rdist to specify the command name for rdistd. This allows rdistd to be placed in locations that are not in the system default (for SVR4 systems) or user's (for some other types of systems) path. Any comments on this change? I personally don't like extra options, but I don't see a way around this. If someone else has a workaround, please let me know. Peter F. Patel-Schneider AT&T Bell Labs; 600 Mountain Avenue, 2C-405; Murray Hill, NJ 07974; U.S.A. pfps@research.att.com Here are some examples of this option in action: getafix 158> rdist -w -R -p /opt/rdistd -c . getafix:/tmp/pfps getafix: updating host getafix getafix: LOCAL ERROR: Unexpected input at startup: "/opt/rdistd: Command not found". getafix 161> rdist -w -R -p /opt/bin/rdistd -c . getafix:/tmp/pfps getafix: updating host getafix getafix: ./src/docmd.c: updating getafix: updating of getafix finished Here are the context diffs for the doc and src directories for this option. diff -cr doc.orig/rdist.man doc/rdist.man *** doc.orig/rdist.man Tue Sep 28 20:30:52 1993 --- doc/rdist.man Tue Sep 28 19:55:16 1993 *************** *** 81,86 **** --- 81,90 ---- .B \-t .I timeout ] + [ + .B \-p + .I + ] [ .I name ... ] *************** *** 176,182 **** .fi on each target host. .I Rdist ! does not specify the absolute pathname to .I rdistd on the target host in order to avoid imposing any policy on where .I rdistd --- 180,186 ---- .fi on each target host. .I Rdist ! can specify the pathname to .I rdistd on the target host in order to avoid imposing any policy on where .I rdistd *************** *** 387,392 **** --- 391,399 ---- .I rdist server. The default is 900 seconds. + .TP + .B "\-p \fI\fR" + Set the path where the rdistd server is searched for on the target host. .TP .B \-V Print version information and exit. diff -cr src.bugfix/docmd.c src/docmd.c *** src.bugfix/docmd.c Tue Sep 28 19:00:00 1993 --- src/docmd.c Tue Sep 28 20:00:41 1993 *************** *** 60,65 **** --- 60,66 ---- extern int activechildren; extern int maxchildren; extern int amchild; + extern char *path_rdistd; static void cmptime(); *************** *** 278,284 **** if (!IS_ON(options, DO_QUIET)) message(MT_INFO, "updating host %s", rhost); ! (void) sprintf(buf, "%s -S", _PATH_RDISTD); if (port < 0) { struct servent *sp; --- 279,285 ---- if (!IS_ON(options, DO_QUIET)) message(MT_INFO, "updating host %s", rhost); ! (void) sprintf(buf, "%.*s -S", BUFSIZ-5,path_rdistd); if (port < 0) { struct servent *sp; diff -cr src.bugfix/rdist.c src/rdist.c *** src.bugfix/rdist.c Tue Sep 28 19:00:01 1993 --- src/rdist.c Tue Sep 28 19:25:10 1993 *************** *** 62,69 **** struct group *gr = NULL; /* Static area for getgrent */ char localmsglist[] = "stdout=all:notify=all:syslog=nerror,ferror"; char *remotemsglist = NULL; ! char optchars[] = "A:a:bcd:DFf:hil:L:M:m:NnOo:qRrst:Vvwxy"; FILE *opendist(); main(argc, argv, envp) int argc; --- 62,70 ---- struct group *gr = NULL; /* Static area for getgrent */ char localmsglist[] = "stdout=all:notify=all:syslog=nerror,ferror"; char *remotemsglist = NULL; ! char optchars[] = "A:a:bcd:DFf:hil:L:M:m:NnOo:p:qRrst:Vvwxy"; FILE *opendist(); + char *path_rdistd = _PATH_RDISTD; main(argc, argv, envp) int argc; *************** *** 193,198 **** --- 194,206 ---- optarg); usage(); } + break; + + case 'p': + + path_rdistd = strdup(optarg); + if ( path_rdistd == NULL ) + fatal("Cannot duplicate path to rdistd"); break; /* From erickson@binky.ICS.UCI.EDU Wed Sep 29 06:58:50 1993 Return-Path: Received: from ics.uci.edu (paris.ics.uci.edu) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26313; Wed, 29 Sep 93 06:58:50 PDT Received: from binky.ics.uci.edu by Paris.ics.uci.edu id aa12960; 29 Sep 93 6:55 PDT To: rdist-dev@usc.EDU Subject: problem with rdist under SunOS 5.2 Date: Wed, 29 Sep 1993 06:55:20 -0700 From: Scott Erickson Message-Id: <9309290655.aa12960@Paris.ics.uci.edu> Version: Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 (with and without the NETGROUPS patch) Description: For some reason, I can't run rdist as a non-privileged user. There seems to be some problem with the setuid stuff. Here's a typescript of a session: Script started on Fri Aug 20 15:25:41 1993 %:~(0): uname -a SunOS phoenix.ics.uci.edu 5.2 Generic sun4c sparc %:~(0): ls -Fl /usr/bin/rdist -rwsr-x--x 1 root bin 137124 Aug 20 13:55 /usr/bin/rdist* %:~(1): /usr/bin/rdist -V Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 %:~(0): /usr/bin/rdist -cv .cshrc cupid cupid: updating host cupid cupid: LOCAL ERROR: setreuid(561, 0) failed: Not owner (ruid = 0 euid = 0) %:~(1): exit script done on Fri Aug 20 15:26:27 1993 The program is suid to root. If someone knows more about this, I'd appreciate some pointers. rdist seems to work fine under SunOS 4.1.2 (sun4c), Sequent DYNIX, and HPUX A.B8.05. /se University of California Irvine | 714/856-4035 Information and Computer Science Department | erickson@ics.uci.edu UNIX Support Group | ucbvax!ucivax!erickson From marc@Synergytics.Com Wed Sep 29 07:39:32 1993 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27588; Wed, 29 Sep 93 07:39:32 PDT Received: by synergy.Synergytics.Com; id AA02676; Wed, 29 Sep 1993 10:41:35 -0400 Received: from localhost by synergy.Synergytics.Com; (5.65/1.1.3.9/15Apr93-0824AM) id AA02676; Wed, 29 Sep 1993 10:41:35 -0400 Message-Id: <9309291441.AA02676@synergy.Synergytics.Com> Reply-To: Marc@Synergytics.Com To: Scott Erickson Cc: rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Wed, 29 Sep 93 06:55:20 PDT." <9309290655.aa12960@Paris.ics.uci.edu> Date: Wed, 29 Sep 93 10:41:35 +0100 From: Marc Evans - Contract Software Hacker X-Mts: smtp Hi - I have found that I needed the following changes to run on SVR4.0 (Dell i486) and SVR4.2 (NEC r4400). NOTE that I did NOT use #if's everyplace that I should have, so do not consider this a clean patch... diff -rc rdist/src/Makefile.real RDIST/src/Makefile.real *** rdist/src/Makefile.real Fri Jul 16 17:28:50 1993 --- RDIST/src/Makefile.real Wed Sep 8 15:10:51 1993 *************** *** 80,86 **** install: $(CLIENT_BIN) $(SERVER_BIN) $(INSTALL) ${IN_ARGS} -o root -m 4751 \ $(CLIENT_BIN) $(BIN_DIR)/$(CLIENT) ! $(INSTALL) ${IN_ARGS} -o ${BIN_OWNER} -m ${BIN_MODE} \ $(SERVER_BIN) $(BIN_DIR)/$(SERVER) install.man: --- 80,86 ---- install: $(CLIENT_BIN) $(SERVER_BIN) $(INSTALL) ${IN_ARGS} -o root -m 4751 \ $(CLIENT_BIN) $(BIN_DIR)/$(CLIENT) ! $(INSTALL) ${IN_ARGS} -o root -m 4751 \ $(SERVER_BIN) $(BIN_DIR)/$(SERVER) install.man: diff -rc rdist/src/client.c RDIST/src/client.c *** rdist/src/client.c Thu Jul 29 15:37:59 1993 --- RDIST/src/client.c Sun Sep 26 07:04:00 1993 *************** *** 725,732 **** /* * Target exists, but no other info passed */ ! if (n <= 1 || !S_ISREG(statp->st_mode)) return(US_OUTDATE); if (IS_ON(opts, DO_COMPARE)) return(US_DOCOMP); --- 725,736 ---- /* * Target exists, but no other info passed */ ! if (n <= 1 || !S_ISREG(statp->st_mode)) { ! debugmsg(DM_CALL, ! "update(%s,) Target exists, but no other info passed\n", ! rname); return(US_OUTDATE); + } if (IS_ON(opts, DO_COMPARE)) return(US_DOCOMP); *************** *** 796,801 **** --- 800,806 ---- target); return(US_NOTHING); } + debugmsg(DM_MISC, "update(%s,) modified time older\n", rname); return(US_OUTDATE); } *************** *** 807,820 **** * and such. */ if (!IS_ON(opts, DO_NOCHKMODE) && lmode != rmode) { ! debugmsg(DM_MISC, "modes do not match (%d != %d).\n", ! lmode, rmode); return(US_OUTDATE); } if (statp->st_size != size) { ! debugmsg(DM_MISC, "size does not match (%d != %d).\n", ! statp->st_size, size); return(US_OUTDATE); } --- 812,825 ---- * and such. */ if (!IS_ON(opts, DO_NOCHKMODE) && lmode != rmode) { ! debugmsg(DM_MISC,"update(%s,) modes do not match (%d != %d).\n", ! rname, lmode, rmode); return(US_OUTDATE); } if (statp->st_size != size) { ! debugmsg(DM_MISC,"update(%s,) sizes do not match (%d != %d).\n", ! rname, statp->st_size, size); return(US_OUTDATE); } *************** *** 827,834 **** if (strcmp(owner, getusername(statp->st_uid, target, opts)) != 0) { debugmsg(DM_MISC, ! "owner does not match (%s != %s).\n", ! getusername(statp->st_uid, target, opts), owner); return(US_OUTDATE); } --- 832,839 ---- if (strcmp(owner, getusername(statp->st_uid, target, opts)) != 0) { debugmsg(DM_MISC, ! "update(%s,) owners do not match (%s != %s).\n", ! rname, getusername(statp->st_uid, target, opts), owner); return(US_OUTDATE); } *************** *** 838,845 **** ++owner; if (owner && atoi(owner) != statp->st_uid) { debugmsg(DM_MISC, ! "owner does not match (%d != %s).\n", ! statp->st_uid, owner); return(US_OUTDATE); } } --- 843,850 ---- ++owner; if (owner && atoi(owner) != statp->st_uid) { debugmsg(DM_MISC, ! "update(%s,) owners do not match (%d != %s).\n", ! rname, statp->st_uid, owner); return(US_OUTDATE); } } *************** *** 851,858 **** if (strcmp(group, getgroupname(statp->st_gid, target, opts)) != 0) { debugmsg(DM_MISC, ! "group does not match (%s != %s).\n", ! getgroupname(statp->st_gid, target, opts), group); return(US_OUTDATE); } --- 856,863 ---- if (strcmp(group, getgroupname(statp->st_gid, target, opts)) != 0) { debugmsg(DM_MISC, ! "update(%s,) groups do not match (%s != %s).\n", ! rname, getgroupname(statp->st_gid, target, opts), group); return(US_OUTDATE); } *************** *** 862,874 **** ++group; if (group && atoi(group) != statp->st_gid) { debugmsg(DM_MISC, ! "group does not match (%d != %s).\n", ! statp->st_gid, group); return(US_OUTDATE); } } } - return(US_NOTHING); } --- 867,878 ---- ++group; if (group && atoi(group) != statp->st_gid) { debugmsg(DM_MISC, ! "update(%s,) groups do not match (%d != %s).\n", ! rname, statp->st_gid, group); return(US_OUTDATE); } } } return(US_NOTHING); } *************** *** 1004,1010 **** return(1); } if (!IS_ON(opts, DO_QUIET)) ! message(MT_CHANGE, "%s: updating", target); } if (sendfile(rname, opts, &stb, user, group, destdir) == 0) didupdate = 1; --- 1008,1015 ---- return(1); } if (!IS_ON(opts, DO_QUIET)) ! message(MT_CHANGE, "%s: updating (%d)", ! target, stb.st_mode); } if (sendfile(rname, opts, &stb, user, group, destdir) == 0) didupdate = 1; diff -rc rdist/src/common.c RDIST/src/common.c *** rdist/src/common.c Thu Jul 15 18:23:33 1993 --- RDIST/src/common.c Fri Sep 17 11:25:42 1993 *************** *** 93,103 **** /* * Do run-time initialization */ ! extern int init(argc, argv, envp) /*ARGSUSED*/ int argc; char **argv; char **envp; { register int i; --- 93,104 ---- /* * Do run-time initialization */ ! extern int init(argc, argv, envp, server) /*ARGSUSED*/ int argc; char **argv; char **envp; + int server; { register int i; *************** *** 118,124 **** setargs_settup(argc, argv, envp); #endif /* SETARGS */ ! pw = getpwuid(userid = getuid()); if (pw == NULL) { error("Your user id (%d) is not known to this system.", getuid()); --- 119,129 ---- setargs_settup(argc, argv, envp); #endif /* SETARGS */ ! if (server) ! userid = geteuid(); ! else ! userid = getuid(); ! pw = getpwuid(userid); if (pw == NULL) { error("Your user id (%d) is not known to this system.", getuid()); *************** *** 642,648 **** --- 647,657 ---- { int r; + #if !defined(SVR4) r = setreuid(ruid, euid); + #else + r = setuid(getuid()); + #endif if (r < 0) error("setreuid(%d, %d) failed: %s (ruid = %d euid = %d)", ruid, euid, SYSERR, getuid(), geteuid()); diff -rc rdist/src/docmd.c RDIST/src/docmd.c *** rdist/src/docmd.c Fri Jul 16 17:17:33 1993 --- RDIST/src/docmd.c Thu Sep 16 15:27:46 1993 *************** *** 295,302 **** --- 295,304 ---- (void) fflush(stdout); (void) fflush(stderr); + #if !defined(SVR4) if (dosetreuid(userid, 0) != 0) exit(1); + #endif (void) signal(SIGALRM, sighandler); (void) alarm(RTIMEOUT); rem = rcmd(&rhost, port, locuser, ruser, buf, 0); diff -rc rdist/src/rdist.c RDIST/src/rdist.c *** rdist/src/rdist.c Wed Jul 28 21:01:00 1993 --- RDIST/src/rdist.c Fri Sep 17 11:25:51 1993 *************** *** 89,95 **** usage(); } ! if (init(argc, argv, envp) < 0) exit(1); /* --- 89,95 ---- usage(); } ! if (init(argc, argv, envp, 0) < 0) exit(1); /* *************** *** 111,118 **** --- 111,120 ---- exit(1); } + #if !defined(SVR4) if (dosetreuid(0, userid) != 0) exit(1); + #endif while ((c = getopt(argc, argv, optchars)) != -1) switch (c) { diff -rc rdist/src/rdistd.c RDIST/src/rdistd.c *** rdist/src/rdistd.c Tue Oct 13 19:27:45 1992 --- RDIST/src/rdistd.c Fri Sep 17 11:25:59 1993 *************** *** 67,73 **** char *cp; int c; ! if (init(argc, argv, envp) < 0) exit(1); while ((c = getopt(argc, argv, "SDV")) != -1) --- 67,73 ---- char *cp; int c; ! if (init(argc, argv, envp, 1) < 0) exit(1); while ((c = getopt(argc, argv, "SDV")) != -1) diff -rc rdist/src/server.c RDIST/src/server.c *** rdist/src/server.c Fri Jul 16 17:20:28 1993 --- RDIST/src/server.c Thu Sep 16 14:29:21 1993 *************** *** 95,101 **** /* * We assume only the Superuser can change uid ownership. */ ! if (getuid() == 0) { #if defined(HAVE_FCHOWN) if (fd != -1) status = fchown(fd, (CHOWN_UID_T) uid, --- 95,101 ---- /* * We assume only the Superuser can change uid ownership. */ ! if (geteuid() == 0) { #if defined(HAVE_FCHOWN) if (fd != -1) status = fchown(fd, (CHOWN_UID_T) uid, - Marc /| _____________________ ~ . ~ X|=| |__________________ ~ . X| | Marc N. Evans | |_______________________________ X| | Software Consultant | Synergytics | | X| | (603) 635-3857 | 21 Hinds Lane | Specializing in: | X|=|_____________________| Pelham, NH 03076 | - Unix internals/applications | X| (____________________| - X11 internals/applications | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From aad@dvorak.amd.com Wed Sep 29 08:02:25 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28783; Wed, 29 Sep 93 08:02:25 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA15242 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 08:02:25 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA09602 (5.67a/RELAY-IDA-1.2+AMD2.0 for ); Wed, 29 Sep 1993 08:02:23 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA27066; Wed, 29 Sep 93 10:02:22 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA16474; Wed, 29 Sep 93 10:02:22 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.sun4.41 via MS.5.6.lovecraft.sun4_41; Wed, 29 Sep 1993 10:02:21 -0500 (CDT) Message-Id: Date: Wed, 29 Sep 1993 10:02:21 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: new option to rdist to specify path for rdistd In-Reply-To: References: >On SVR4 systems, c-shells started via rcmd don't seem to be login shells, I think that's true pretty much everywhere >and thus don't get a full user environment. Only if their . files are misconfigured. I've seen a lot of people insist on setting things in .login that really belong in .cshrc. You just have to be careful to only run stty if you've got a login shell. ======================================================================8--< From dbeusee@us.oracle.com Wed Sep 29 08:23:26 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29756; Wed, 29 Sep 93 08:23:26 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA20538; Wed, 29 Sep 93 08:23:15 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21069; Wed, 29 Sep 93 08:18:30 PDT Message-Id: <9309291518.AA21069@dbeusee.us.oracle.com> Date: Wed, 29 Sep 93 08:18:30 PDT From: Don Beusee To: erickson@binky.ICS.UCI.EDU, rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 Its because of this: #define setreuid(a,b) setuid(a),seteuid(b) I don't have access to any of our SunOS 5 systems, but with the experience I've had with Dynix/Ptx, I know the problem. The above define is not a valid replacement for setreuid(). Doesn't SunOS5 support setreuid() ?? Try adding a #undef setreuid in config/os-sunos5.h (after the #include "os-svr4.h") to find out. I did not realize until now that the dcosx port (which I provided to Mike) does not properly deal with setreuid(). The os-dcosx.h should have an #undef setreuid after the include. Mike, please apply this patch to os-dcosx.h: *** 1.1 1993/09/29 14:43:12 --- os-dcosx.h 1993/09/29 14:45:35 *************** *** 42,47 **** --- 42,50 ---- */ #include "os-svr4.h" + /* dcosx has setreuid in libucb.a (part of the std ucb compat). */ + #undef setreuid + /* * Signal that can be used to test whether an rdist child process * is still running. This should be a signal that is not used for Mike, did I send you the ncr and ftx (stratus svr4) ports yet? let me know. They also need the #undef setreuid. Regards, Don. From erickson@binky.ICS.UCI.EDU Wed Sep 29 07:20:32 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20568; Wed, 29 Sep 93 07:19:57 PDT Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA18369; Wed, 29 Sep 93 07:24:33 PDT Received: from ics.uci.edu (paris.ics.uci.edu) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26313; Wed, 29 Sep 93 06:58:50 PDT Received: from binky.ics.uci.edu by Paris.ics.uci.edu id aa12960; 29 Sep 93 6:55 PDT To: rdist-dev@usc.EDU Subject: problem with rdist under SunOS 5.2 Date: Wed, 29 Sep 1993 06:55:20 -0700 From: Scott Erickson Message-Id: <9309290655.aa12960@Paris.ics.uci.edu> Status: R Version: Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 (with and without the NETGROUPS patch) Description: For some reason, I can't run rdist as a non-privileged user. There seems to be some problem with the setuid stuff. Here's a typescript of a session: Script started on Fri Aug 20 15:25:41 1993 %:~(0): uname -a SunOS phoenix.ics.uci.edu 5.2 Generic sun4c sparc %:~(0): ls -Fl /usr/bin/rdist -rwsr-x--x 1 root bin 137124 Aug 20 13:55 /usr/bin/rdist* %:~(1): /usr/bin/rdist -V Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 %:~(0): /usr/bin/rdist -cv .cshrc cupid cupid: updating host cupid cupid: LOCAL ERROR: setreuid(561, 0) failed: Not owner (ruid = 0 euid = 0) %:~(1): exit script done on Fri Aug 20 15:26:27 1993 The program is suid to root. If someone knows more about this, I'd appreciate some pointers. rdist seems to work fine under SunOS 4.1.2 (sun4c), Sequent DYNIX, and HPUX A.B8.05. /se University of California Irvine | 714/856-4035 Information and Computer Science Department | erickson@ics.uci.edu UNIX Support Group | ucbvax!ucivax!erickson From dbeusee@us.oracle.com Wed Sep 29 08:32:49 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00387; Wed, 29 Sep 93 08:32:49 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA21036; Wed, 29 Sep 93 08:32:44 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21189; Wed, 29 Sep 93 08:27:59 PDT Message-Id: <9309291527.AA21189@dbeusee.us.oracle.com> Date: Wed, 29 Sep 93 08:27:59 PDT From: Don Beusee To: pfps@research.att.com Subject: Re: new option to rdist to specify path for rdistd Cc: rdist-dev@usc.edu The problem is not specific to svr4. ALL versions of csh will read ~/.cshrc None of them will read ~/.login when doing rsh "cmd", because it is not truely a login shell (on ANY unix platform). Putting rdistd in different places is a hard way to maintain rdistd, but if thats what you want to do, include a statement like this: set path=(/opt/rdist $path) in /.cshrc and it should find rdist (assuming its in /opt/rdist on that system). Just be aware that when you change path in .cshrc it will affect scripts written in csh if you don't put -f on the #!/bin/csh line or if your platform does not support -f. The path will also affect interactive and login shells, since csh reads .cshrc unless -f option used. Regards, Don. From pfps@research.att.com Wed Sep 29 08:13:03 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21050; Wed, 29 Sep 93 08:12:38 PDT Received: from research.att.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA20304; Wed, 29 Sep 93 08:17:14 PDT Received: by inet; Wed Sep 29 11:16 EDT 1993 Received: by hunny.research.att.com (/\==/\ Smail3.1.25.1 #25.11) id ; Wed, 29 Sep 93 11:17 EDT Received: by idefix.research.att.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 29 Sep 93 11:17 EDT Message-Id: Date: Wed, 29 Sep 93 11:17 EDT From: pfps@research.att.com (Peter F. Patel-Schneider) To: dbeusee@us In-Reply-To: <9309291352.AA20388@dbeusee.us.oracle.com> (message from Don Beusee on Wed, 29 Sep 93 06:52:40 PDT) Subject: Re: new option to rdist to specify path for rdistd Status: R You suggest using a complete path for _PATH_RDISTD to get around the problem of SVR4 not setting up a complete user environment for rcmd-started "logins". The problem with specifying the path this way is that you may want to talk to systems that keep rdistd in different places. I prefer the suggestion by Michael Platoff. peter From dbeusee@us.oracle.com Wed Sep 29 08:43:25 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00941; Wed, 29 Sep 93 08:43:25 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA22235; Wed, 29 Sep 93 08:43:21 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21284; Wed, 29 Sep 93 08:38:36 PDT Message-Id: <9309291538.AA21284@dbeusee.us.oracle.com> Date: Wed, 29 Sep 93 08:38:36 PDT From: Don Beusee To: aad@dvorak.amd.com, rdist-dev@usc.edu Subject: Re: new option to rdist to specify path for rdistd > Only if their . files are misconfigured. I've seen a lot of people > insist on setting things in .login that really belong in .cshrc. You > just have to be careful to only run stty if you've got a login shell. This is a religious comment. stty does not belong in .cshrc regardless. Thats what .login is for. .login is for commands you only want executed when you are really logging into the machine with an interactive shell. Anything else (like which file should have $path set from) is purely depending on someone's taste, and depends on what kind of environment the user wants. My own personal taste is to keep $path in .login so that scripts written in csh (which by accident don't have -f, or purposely if the poorly written script uses an alias) will use the path the user is running with. There is no reason to have a script run with a different path than any other unix command, unless the script needs to purposely alter it during its execution. Enough on the religious aspects. Regards, Don. From aad@dvorak.amd.com Wed Sep 29 08:23:24 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21165; Wed, 29 Sep 93 08:22:49 PDT Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA20742; Wed, 29 Sep 93 08:27:15 PDT Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28783; Wed, 29 Sep 93 08:02:25 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA15242 (5.67a/IDA-1.5 for ); Wed, 29 Sep 1993 08:02:25 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA09602 (5.67a/RELAY-IDA-1.2+AMD2.0 for ); Wed, 29 Sep 1993 08:02:23 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA27066; Wed, 29 Sep 93 10:02:22 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA16474; Wed, 29 Sep 93 10:02:22 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.sun4.41 via MS.5.6.lovecraft.sun4_41; Wed, 29 Sep 1993 10:02:21 -0500 (CDT) Message-Id: Date: Wed, 29 Sep 1993 10:02:21 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: new option to rdist to specify path for rdistd In-Reply-To: References: Status: R >On SVR4 systems, c-shells started via rcmd don't seem to be login shells, I think that's true pretty much everywhere >and thus don't get a full user environment. Only if their . files are misconfigured. I've seen a lot of people insist on setting things in .login that really belong in .cshrc. You just have to be careful to only run stty if you've got a login shell. ======================================================================8--< From mcooper@ucs.usc.edu Wed Sep 29 11:29:35 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09812; Wed, 29 Sep 93 11:29:35 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA16456; Wed, 29 Sep 93 11:29:33 PDT Sender: "Michael A. Cooper" Date: Wed, 29 Sep 93 11:29:32 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: pfps@research.att.com (Peter F. Patel-Schneider) Cc: rdist-dev@usc.edu Subject: Re: new option to rdist to specify path for rdistd In-Reply-To: Your message of Wed, 29 Sep 93 09:11 EDT Message-Id: Content-Length: 76 That's been on my TODO list for a while now. Thanks for the diff's. mike From mcooper@ucs.usc.edu Wed Sep 29 11:36:43 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10243; Wed, 29 Sep 93 11:36:43 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA16510; Wed, 29 Sep 93 11:36:41 PDT Sender: "Michael A. Cooper" Date: Wed, 29 Sep 93 11:36:40 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Scott Erickson Cc: rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Wed, 29 Sep 1993 06:55:20 -0700 Message-Id: Content-Length: 67 That's a known bug which is fixed in the next release. :-) mike From tim.spencer@mccaw.com Mon Oct 4 18:57:43 1993 Return-Path: Received: from mccaw.com (wombat.mccaw.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24612; Mon, 4 Oct 93 18:57:43 PDT Received: from enterprise.krldwa.mccaw.com ([155.176.15.31]) by mccaw.com (4.1/SMI-4.1) id AA05902; Mon, 4 Oct 93 19:05:45 PDT Received: from axys69.axysdev.krldwa.mccaw.com by enterprise.krldwa.mccaw.com (4.1/SMI-4.1, dpg hack 20apr93) id AA14657; Mon, 4 Oct 93 18:57:39 PDT Received: from kiwi by axys69.axysdev.krldwa.mccaw.com (NX5.67c/NX3.0M, dpg hack 20apr93) id AA07615; Mon, 4 Oct 93 18:57:38 -0700 From: Tim Spencer Message-Id: <9310050157.AA07615@axys69.axysdev.krldwa.mccaw.com> Received: by kiwi.mis.krldwa.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA01188; Mon, 4 Oct 93 18:57:37 -0700 Date: Mon, 4 Oct 93 18:57:37 -0700 Received: by NeXT.Mailer (1.95) Received: by NeXT Mailer (1.95) To: rdist-dev@usc.edu Subject: rdist polling? rexec() vs. rcmd()? compression? Hello all! Has anybody gotten a good rdist polling solution working? What I'd like to do is have client machines that automatically poll their distribution server for new software when they come up in case they were down during a software update. Also, I have put in in -p and -P passwordfile options that would ask for a password using getpass() and read one in from a temporary file (for scripting purposes) so that we can use rexec() rather than rcmd(). The default would still be to use rcmd(), but are there any security issues that I should be aware of that would make this method unsafe? Has anybody done anything with a builtin compression routine to make rdisting over slow (netblazer PN) lines better? I currently have put in a quick and dirty hack that uses system() and gzip, but I'd rather this thing be self contained. I hope that I'm not flamed for rehashing any sort of old information that is easily available! Anything that you can do to help me out would make me very happy, and I would be equally happy to summarize and show people what I have done if there is any interest... Please email me at tim.spencer@mccaw.com. Have fun! --- Tim Spencer: McCaw NeXT Technical Analyst tim.spencer@mccaw.com (206)915-5988 or (206)827-4500x1212 :-) NeXTMail welcome!! From tim.spencer@mccaw.com Tue Oct 5 11:21:33 1993 Return-Path: Received: from mccaw.com (wombat.mccaw.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00859; Tue, 5 Oct 93 11:21:33 PDT Received: from enterprise.krldwa.mccaw.com ([155.176.15.31]) by mccaw.com (4.1/SMI-4.1) id AA06654; Tue, 5 Oct 93 11:29:33 PDT Received: from axys69.axysdev.krldwa.mccaw.com by enterprise.krldwa.mccaw.com (4.1/SMI-4.1, dpg hack 20apr93) id AA16897; Tue, 5 Oct 93 11:21:23 PDT Received: from kiwi by axys69.axysdev.krldwa.mccaw.com (NX5.67c/NX3.0M, dpg hack 20apr93) id AA10596; Tue, 5 Oct 93 11:21:20 -0700 From: Tim Spencer Message-Id: <9310051821.AA10596@axys69.axysdev.krldwa.mccaw.com> Received: by kiwi.mis.krldwa.mccaw.com (NX5.67d/NX3.0X, dpg hack 20mar93) id AA00377; Tue, 5 Oct 93 11:21:19 -0700 Date: Tue, 5 Oct 93 11:21:19 -0700 Received: by NeXT.Mailer (1.95) Received: by NeXT Mailer (1.95) To: rdist-dev@usc.edu Subject: Any reason why we must be root to use rdist? I noticed that in rdist 6, setreuid() calls are checked to see if they worked, and it bombs out if it doesn't. In version 5.8, it does not, and thus allows users other than root to use rdist to their own accounts and stuff. Is there a security breach in that sort of usage somehow? Why is that code in there? I'm just seeing if it would be a bad thing for me to take it out. Please feel free to email me at tim.spencer@mccaw.com if you have any input... Thanks! --- Tim Spencer: McCaw NeXT Technical Analyst tim.spencer@mccaw.com (206)915-5988 or (206)827-4500x1212 :-) NeXTMail welcome!! From mcooper@ucs.usc.edu Tue Oct 5 12:20:22 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04378; Tue, 5 Oct 93 12:20:22 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA25658; Tue, 5 Oct 93 11:34:35 PDT Sender: "Michael A. Cooper" Date: Tue, 5 Oct 93 11:34:35 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Tim Spencer Cc: rdist-dev@usc.edu Subject: Re: Any reason why we must be root to use rdist? In-Reply-To: Your message of Tue, 5 Oct 93 11:21:19 -0700 Message-Id: Content-Length: 0 Normal users are suppose to be able to run rdist. There are a few systems, such as SunOS 5.x and generic SVR4, where rdist 6.1beta.1 doesn't work for normal users. This will be fixed in the next release. mike From dbeusee@us.oracle.com Sat Oct 16 12:56:29 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20074; Sat, 16 Oct 93 12:56:29 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA26385; Sat, 16 Oct 93 12:56:20 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00911; Sat, 16 Oct 93 12:51:44 PDT Message-Id: <9310161951.AA00911@dbeusee.us.oracle.com> Date: Sat, 16 Oct 93 12:51:44 PDT From: Don Beusee To: mcooper@usc.edu Subject: rdist 61b2 patches Cc: rdist-dev@usc.edu Mike, Here is a .shar file of the patches I put in 61b2 for my ports. I sent most (if not all) of these before, but they did not make it in your release. os-type that comes with 61b1 and 61b2 does not work on at least one of my ports because uname returns the wrong thing. Please put my version back in the release and add whatever other ports you received from others. Just do diff -b to see which ports are missing from this version. This is the same os-type file I sent you before (with ncr added). I put my BASEFILE patch back in. I did not hear from you if you decided for or against it. I hope you don't mind keeping it in (I'm using it all over). You can ignore pathnames.patch (its in my 'patches' directory which contains all my patches). Perhaps you should move this to config.h, since this is really a site specific thing. Also, for the parallel rdist, child.c really needs the sleep() after forking. sleep.patch contains this patch. Without the sleep, some hosts do not get updated. The rest are porting fixes. cast*.patch fixes some casting errors. I forget which port complains (maybe ncr). The rest should be self-explanitory. Attached is the .shar file. Regards, Don. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # Makefile # basefile.patch # basefile2.patch # cast.patch # cast2.patch # cxux.patch # makeall # mf.hpux.patch # mf.ncr # os-dynix.h.patch # os-ncr.h # os-type # pathnames.patch # sleep.patch # sed 's/^X//' << 'SHAR_EOF' > Makefile && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: Makefile,v 1.1 1993/10/11 08:54:50 dbeusee Exp $ X# X X# X# Main top-level Makefile X# X Xall install install.man clean: FRC X @./makeall $@ X XFRC: SHAR_EOF chmod 0644 Makefile || echo "restore of Makefile fails" sed 's/^X//' << 'SHAR_EOF' > basefile.patch && X*** 1.2 1993/04/04 02:06:13 X--- 1.3 1993/04/04 05:18:54 X*************** X*** 145,154 **** X if (IS_ON(opts, DO_VERIFY)) X continue; X (void) sendcmd(C_SPECIAL, X! "%s=%s;%s=%s;export %s %s;%s", X E_LOCFILE, starget, X E_REMFILE, rfile, X! E_LOCFILE, E_REMFILE, X sc->sc_name); X while (response() > 0) X ; X--- 145,155 ---- X if (IS_ON(opts, DO_VERIFY)) X continue; X (void) sendcmd(C_SPECIAL, X! "%s=%s;%s=%s;%s=%s;export %s %s %s;%s", X E_LOCFILE, starget, X E_REMFILE, rfile, X! E_BASEFILE, basename(rfile), X! E_LOCFILE, E_REMFILE, E_BASEFILE, X sc->sc_name); X while (response() > 0) X ; SHAR_EOF chmod 0644 basefile.patch || echo "restore of basefile.patch fails" sed 's/^X//' << 'SHAR_EOF' > basefile2.patch && X*** 1.1 1993/04/04 02:15:36 X--- defs.h 1993/04/04 05:19:27 X*************** X*** 34,40 **** X */ X X /* X! * $Id: defs.h,v 1.1 1993/04/04 02:15:36 dbeusee Exp $ X * @(#)defs.h 5.2 (Berkeley) 3/20/86 X */ X X--- 34,40 ---- X */ X X /* X! * $Id: defs.h,v 1.2 1993/04/04 05:19:17 dbeusee Exp $ X * @(#)defs.h 5.2 (Berkeley) 3/20/86 X */ X X*************** X*** 246,251 **** X--- 246,252 ---- X #define E_FILES "FILES" /* List of files */ X #define E_LOCFILE "FILE" /* Local Filename */ X #define E_REMFILE "REMFILE" /* Remote Filename */ X+ #define E_BASEFILE "BASEFILE" /* basename of Remote File */ X X /* X * Suffix to use when saving files SHAR_EOF chmod 0644 basefile2.patch || echo "restore of basefile2.patch fails" sed 's/^X//' << 'SHAR_EOF' > cast.patch && X*** 1.1 1993/10/10 14:06:03 X--- client.c 1993/10/11 07:51:46 X*************** X*** 782,788 **** X /* X * File needs to be updated? X */ X! lmode = otoi(statp->st_mode & 07777); X X debugmsg(DM_MISC, "update(%s,) local mode %d remote mode %d\n", X rname, lmode, rmode); X--- 783,789 ---- X /* X * File needs to be updated? X */ X! lmode = otoi( ( (int)statp->st_mode ) & 07777); X X debugmsg(DM_MISC, "update(%s,) local mode %d remote mode %d\n", X rname, lmode, rmode); SHAR_EOF chmod 0644 cast.patch || echo "restore of cast.patch fails" sed 's/^X//' << 'SHAR_EOF' > cast2.patch && X*** 1.1 1993/10/11 08:48:28 X--- common.c 1993/10/11 08:49:11 X*************** X*** 786,792 **** X char *ptr; X extern POINTER *malloc(); X X! if ((ptr = malloc(amt)) == NULL) X fatal("Cannot malloc %d bytes of memory.", amt); X X return(ptr); X--- 786,792 ---- X char *ptr; X extern POINTER *malloc(); X X! if ((ptr = (char *)malloc(amt)) == NULL) X fatal("Cannot malloc %d bytes of memory.", amt); X X return(ptr); X*************** X*** 802,808 **** X char *new; X extern POINTER *realloc(); X X! if ((new = realloc(baseptr, amt)) == NULL) X fatal("Cannot realloc %d bytes of memory.", amt); X X return(new); X--- 802,808 ---- X char *new; X extern POINTER *realloc(); X X! if ((new = (char *)realloc(baseptr, amt)) == NULL) X fatal("Cannot realloc %d bytes of memory.", amt); X X return(new); X*************** X*** 818,824 **** X char *ptr; X extern POINTER *calloc(); X X! if ((ptr = calloc(num, esize)) == NULL) X fatal("Cannot calloc %d * %d = %d bytes of memory.", X num, esize, num * esize); X X--- 818,824 ---- X char *ptr; X extern POINTER *calloc(); X X! if ((ptr = (char *)calloc(num, esize)) == NULL) X fatal("Cannot calloc %d * %d = %d bytes of memory.", X num, esize, num * esize); X SHAR_EOF chmod 0644 cast2.patch || echo "restore of cast2.patch fails" sed 's/^X//' << 'SHAR_EOF' > cxux.patch && X*** 1.1 1993/10/11 08:30:15 X--- isexec.c 1993/10/11 08:30:48 X*************** X*** 76,82 **** X--- 76,84 ---- X /* X * COFF X */ X+ #ifndef CXUX X #include X+ #endif X X #if !defined(ISCOFF) X SHAR_EOF chmod 0644 cxux.patch || echo "restore of cxux.patch fails" sed 's/^X//' << 'SHAR_EOF' > makeall && X#!/bin/sh X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: makeall,v 1.1 1993/10/11 08:54:50 dbeusee Exp $ X# X X# X# Main top-level Makefile X# X XMAKE=make XTARGETS="src config doc support mf" X Xif [ "$1" = "clean" ]; then X echo rm -f *~ a.out core \#* X rm -f *~ a.out core \#* Xfi X Xfor t in $TARGETS; do X echo Making \"$1\" in \"$t\" X (cd $t; $MAKE $1) Xdone SHAR_EOF chmod 0755 makeall || echo "restore of makeall fails" sed 's/^X//' << 'SHAR_EOF' > mf.hpux.patch && X*** 1.1 1993/10/11 07:38:28 X--- mf.hpux 1993/10/11 07:38:46 X*************** X*** 47,50 **** X # X # System libraries that we need to load. X # X! LIB_SYS = -lPW X--- 47,50 ---- X # X # System libraries that we need to load. X # X! LIB_SYS = SHAR_EOF chmod 0644 mf.hpux.patch || echo "restore of mf.hpux.patch fails" sed 's/^X//' << 'SHAR_EOF' > mf.ncr && X# X# Copyright (c) 1993 Michael A. Cooper X# Copyright (c) 1993 Regents of the University of California. X# All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# $Id: mf.ncr,v 6.0 1993/02/20 23:36:21 mcooper Exp $ X# X X# X# ncr Makefile X# X X# X# Functions that are missing in this OS are contained in the X# files specified in ${MISSINGOBJS}. X# XMISSINGOBJS = $(O)strcasecmp.o $(O)regex.o $(O)strtol.o $(O)hasmntopt.o X X# X# System libraries that we need to load. X# XLIB_SYS = -lnsl -lsocket -lc /usr/ucblib/libucb.a X X# X# No ranlib X# XRANLIB = SHAR_EOF chmod 0644 mf.ncr || echo "restore of mf.ncr fails" sed 's/^X//' << 'SHAR_EOF' > os-dynix.h.patch && X*** 1.1 1993/10/11 07:43:31 X--- os-dynix.h 1993/10/11 11:13:06 X*************** X*** 140,142 **** X--- 140,147 ---- X * We have fchmod() X */ X #define HAVE_FCHMOD X+ X+ /* X+ * dynix does not have pid_t X+ */ X+ #define pid_t int SHAR_EOF chmod 0644 os-dynix.h.patch || echo "restore of os-dynix.h.patch fails" sed 's/^X//' << 'SHAR_EOF' > os-ncr.h && X/* X * Copyright (c) 1993 Michael A. Cooper X * Copyright (c) 1993 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X/* X * $Id: os-ncr.h,v 6.1 1993/03/20 21:28:37 mcooper Exp mcooper $ X * @(#)os-ncr.h X */ X X/* X * System V Release 4 (ncr) X */ X#include "os-svr4.h" X X#undef setreuid /* ncr svr4 has this. */ X X/* X * Signal that can be used to test whether an rdist child process X * is still running. This should be a signal that is not used for X * anything else. On most systems, SIGUSR1 is appropriate. X */ X#define TEST_SIGNAL SIGUSR1 SHAR_EOF chmod 0644 os-ncr.h || echo "restore of os-ncr.h fails" sed 's/^X//' << 'SHAR_EOF' > os-type && X#!/bin/sh X# X# Copyright (c) 1989 Jan-Simon Pendry X# Copyright (c) 1989 Imperial College of Science, Technology & Medicine X# Copyright (c) 1989 The Regents of the University of California. X# All rights reserved. X# X# This code is derived from software contributed to Berkeley by X# Jan-Simon Pendry at Imperial College, London. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by the University of X# California, Berkeley and its contributors. X# 4. Neither the name of the University nor the names of its contributors X# may be used to endorse or promote products derived from this software X# without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X# SUCH DAMAGE. X# X# %W% (Berkeley) %G% X# X# $Id: os-type,v 1.3 1993/04/05 14:17:32 dbeusee Exp dbeusee $ X# X X# X# Take a pot-shot at your os type X# XOS="" X X# X# Try poking around in /etc/motd X# Xcase "`exec 2>/dev/null; head -2 /etc/motd`" in X*"Sun UNIX 4.2 Release 3."*) OS=sunos3;; X*"SunOS Release 4."*) OS=sunos4;; X*"SunOS 5."*) OS=sunos5;; X*"HP-UX on the HP"*) OS=hpux;; X*"DYNIX(R)"*) OS=dynix;; X*"DYNIX/ptx"*) OS=dynixptx;; X*" dcosx"*) OS=dcosx;; X*"Ultrix V2."*) OS=ultrix2_2;; X*"Ultrix V3."*) OS=ultrix3_0;; X*"Ultrix-32 V3."*) OS=ultrix3_0;; X*"Ultrix Worksystem V2."*) OS=ultrix3_0;; X*"ULTRIX V4.2"*) OS=ultrix4;; X*"ULTRIX V4."*) OS=ultrix4;; X*"HLH OTS Version 1."*) OS=hlh42;; X*"RISC iX release 1."*) OS=riscix;; X*"FPX 4."*) OS=fpx4;; X*"HCX/UX"*) OS=hcx;; X*"CX/UX"*) OS=cxux;; X*"4.4 BSD UNIX"*) OS=bsd44;; X*"4.3 BSD Reno UNIX"*) OS=bsd44;; X*"4.3 BSD UNIX"*) if [ -f /etc/minidisk ]; then X OS=acis43 X elif [ -f /sbin/nfsiod ]; then X OS=bsd44 # prototype X else X OS=xinu43 X fi;; X*"Alliant Concentrix"*) OS=concen;; X*"Umax 4.3"*) OS=umax43;; X*"RISCos 4"*) OS=mipsos4;; X*"DEC OSF/1"*) OS=osf1;; X*"Multiflow 4.3 BSD"*) OS=tracebsd;; X*) X Xif [ -f /version ]; then X OS=ftx Xelif [ -d /ncrm ]; then X OS=ncr Xelse X # X # try uname X # X if [ -f /usr/bin/uname ]; then X uname=/usr/bin/uname X fi X if [ ! -z "${uname}" ]; then X osname="`exec 2>/dev/null; ${uname} -s | tr '[A-Z]' '[a-z]'`" X osver="`exec 2>/dev/null; ${uname} -r`" X osmajver="`exec 2>/dev/null; echo $osver | sed -e 's;\..*;;'`" X case "${osname}${osver}" in X "ultrix"*) OS="${osname}${osmajver}";; X "sunos"*) OS="${osname}${osmajver}";; X "aix"*) X osmajver="`${uname} -v`" X OS="${osname}${osmajver}" X ;; X *) OS="${osname}${osver}";; X esac X fi Xfi X;; Xesac X Xif [ -z "${OS}" ]; then X# X# Well, that didn't work so apply some heuristics X# to the filesystem name space... X# X# echo "# ... inspecting File system ..." >&2 X if [ -f /etc/comply ]; then X OS=utek X elif [ -d /usr/lib/methods -o -d /etc/methods ]; then X OS=aix3 X elif [ -f /etc/nd ]; then X OS=sunos3 X elif [ -f /etc/elcsd ]; then X echo "# ... Ultrix - assuming U4.0 ..." >&2 X OS=ultrix4 X elif [ -f /hp-ux ]; then X OS=hpux X elif [ -f /etc/ttylocal ]; then X OS=xinu43 X elif [ -f /etc/minidisk ]; then X OS=acis43 X elif [ -f /etc/toolboxdaemon ]; then X OS=aux X elif [ -f /sbin/nfsiod ]; then X OS=bsd44 X elif [ -d /vrm ]; then X OS=aix2 X elif [ -f /dynix ]; then X OS=dynix X elif [ -f /bin/pyr ] && /bin/pyr; then X OS=pyrosx X elif [ -d /NextApps ]; then X OS=next X elif [ -f /etc/gl/ucode ]; then X OS=irix3 X elif [ -d /usr/gfx/ucode ]; then X OS=irix4 X elif [ -f /stellix ]; then X OS=stellix X else X case "`(sh ../config/arch)2>/dev/null`" in X ibm032) OS=acis43;; X aviion) OS=dgux;; X *) OS=unknown;; X esac X fi Xfi # ${OS} X Xecho "" >&2 Xecho " OS appears to be \"${OS}\"" >&2 Xecho "" >&2 Xecho "${OS}" Xexit 0 SHAR_EOF chmod 0755 os-type || echo "restore of os-type fails" sed 's/^X//' << 'SHAR_EOF' > pathnames.patch && X46c46 X< # define _PATH_RDISTD "rdistd" /* Rdist server */ X--- X> # define _PATH_RDISTD "/usr/local/bin/rdistd" /* Rdist server */ SHAR_EOF chmod 0644 pathnames.patch || echo "restore of pathnames.patch fails" sed 's/^X//' << 'SHAR_EOF' > sleep.patch && X*** 1.1 1993/07/24 18:10:06 X--- 1.2 1993/07/24 18:18:08 X*************** X*** 33,39 **** X X #ifndef lint X static char RCSid[] = X! "$Id: child.c,v 1.1 1993/07/24 18:10:06 dbeusee Exp $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X--- 33,39 ---- X X #ifndef lint X static char RCSid[] = X! "$Id: child.c,v 1.2 1993/07/24 18:18:08 dbeusee Exp $"; X X static char sccsid[] = "@(#)docmd.c 5.1 (Berkeley) 6/6/85"; X X*************** X*** 478,483 **** X--- 478,485 ---- X * Parent X */ X static CHILD newchild; X+ X+ sleep(2); /* must give child a chance to start */ X X /* Receive notification when the child exits */ X (void) signal(SIGCHLD, reap); SHAR_EOF chmod 0644 sleep.patch || echo "restore of sleep.patch fails" exit 0 From dbeusee@us.oracle.com Sat Oct 16 13:02:40 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20264; Sat, 16 Oct 93 13:02:40 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA26737; Sat, 16 Oct 93 13:02:39 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00916; Sat, 16 Oct 93 12:58:07 PDT Message-Id: <9310161958.AA00916@dbeusee.us.oracle.com> Date: Sat, 16 Oct 93 12:58:07 PDT From: Don Beusee To: mcooper@usc.edu Subject: forgot to mention about the patches Cc: rdist-dev@usc.edu Mike, I forgot to tell you what the makeall and Makefile (the top one) is for. The new addition (if statement) fails on osx. So instead, the Makefile calls the makeall script. Regards, Don. From dbeusee@us.oracle.com Mon Oct 18 19:45:41 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05458; Mon, 18 Oct 93 19:45:41 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA20779; Mon, 18 Oct 93 19:45:13 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA27828; Mon, 18 Oct 93 19:40:40 PDT Message-Id: <9310190240.AA27828@dbeusee.us.oracle.com> Date: Mon, 18 Oct 93 19:40:40 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: permission denied Rdist does not prefix the hostname in the "Permission denied." error if a machine does not allow rsh. This makes it very difficult to tell which machine has the problem. Can you fix this Mike? Regards, Don. seq3: updating host seq3 seq2: updating host seq2 seq1: updating host seq1 seq4: updating host seq4 seq4: /local/.install: updating seq4: special "/local/.install" seq4: /local/etc/sysadmin: updating seq2: /local/.install: updating Permission denied. seq3: updating of seq3 finished . . . From mcooper@ucs.usc.edu Tue Oct 19 10:13:16 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10171; Tue, 19 Oct 93 10:13:16 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA14758; Tue, 19 Oct 93 10:11:43 PDT Sender: "Michael A. Cooper" Date: Tue, 19 Oct 93 10:11:42 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: permission denied In-Reply-To: Your message of Mon, 18 Oct 93 19:40:40 PDT Message-Id: Content-Length: 293 That comes from rshd on the remote host. The rshd should really be the one that prints it's hostname. I made this simple change to most of our rshd's here at USC. We could make rdist prepend the hostname, but that would mean more input processing, but could really slow things down. mike From dbeusee@us.oracle.com Tue Oct 19 10:41:15 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12929; Tue, 19 Oct 93 10:41:15 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA01960; Tue, 19 Oct 93 10:40:43 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA05212; Tue, 19 Oct 93 09:37:37 PDT Message-Id: <9310191637.AA05212@dbeusee.us.oracle.com> Date: Tue, 19 Oct 93 09:37:37 PDT From: Don Beusee To: rdist-dev@usc.edu Subject: rdist -Server not working - here is a patch to fix it diff -r1.1 rdist.c 105c105 < (void) execl(_PATH_OLDRDIST, "-Server", (char *)NULL); --- > (void) execl(_PATH_OLDRDIST, "rdist", "-Server", (char *)NULL); From dbeusee@us.oracle.com Tue Oct 19 18:10:21 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09332; Tue, 19 Oct 93 18:10:21 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA23817; Tue, 19 Oct 93 18:10:01 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09944; Tue, 19 Oct 93 17:54:31 PDT Message-Id: <9310200054.AA09944@dbeusee.us.oracle.com> Date: Tue, 19 Oct 93 17:54:31 PDT From: Don Beusee To: mcooper@usc.edu Subject: Re: permission denied Cc: rdist-dev@usc.edu Why would it "really slow things down"?? Everything else is already prepended with the hostname. I would think all you need to do is move the code to before doing the rcmd(). I did not look to see where rdist sets up the pipe to the parent, but it seems like its not doing it soon enough. We just can't expect all the vendors to fix their rshd's. SO I think we need rdist to do it. From mcooper@skat.usc.edu Tue Oct 19 16:25:04 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08585; Tue, 19 Oct 93 16:25:03 PDT Received: from skat.usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA04330; Tue, 19 Oct 93 16:29:24 PDT Received: from acamar.usc.edu by skat.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA20766; Tue, 19 Oct 93 10:11:42 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA14758; Tue, 19 Oct 93 10:11:43 PDT Sender: "Michael A. Cooper" Date: Tue, 19 Oct 93 10:11:42 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: permission denied In-Reply-To: Your message of Mon, 18 Oct 93 19:40:40 PDT Message-Id: Content-Length: 293 Status: R That comes from rshd on the remote host. The rshd should really be the one that prints it's hostname. I made this simple change to most of our rshd's here at USC. We could make rdist prepend the hostname, but that would mean more input processing, but could really slow things down. mike From dbeusee@us.oracle.com Sat Oct 23 09:21:18 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24956; Sat, 23 Oct 93 09:21:18 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA22046; Sat, 23 Oct 93 09:21:19 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA26075; Sat, 23 Oct 93 09:16:49 PDT Message-Id: <9310231616.AA26075@dbeusee.us.oracle.com> Date: Sat, 23 Oct 93 09:16:49 PDT From: Don Beusee To: mcooper@usc.edu Subject: rdist: pullfrom Cc: rdist-dev@usc.edu Mike, I got a great idea for an rdist enhancement. A "pullfrom" directive. Here's how it would work. Take this example: ${FILES} -> ${HOSTS} pullfrom ${SRCHOST}; install; The above would first pull ${FILES} from ${SRCHOST}, then install them on ${HOSTS}. This has 2 GREAT features: - we can use rdist to pull files instead of requiring the source host to push them. - we can pull from a source host then push (rdist) those files to some other hosts. The pull should obviously use the same rdist mechanism (only update neccessary files). The pullfrom should take the same options as install. If ${HOSTS} is specified as "NOINSTALL", then no install (push) should be done. Example: ${FILES} -> NOINSTALL pullfrom {$SRCHOST}; What do you think? Regards, Don. From dbeusee@us.oracle.com Sat Oct 23 09:30:11 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25013; Sat, 23 Oct 93 09:30:11 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA22335; Sat, 23 Oct 93 09:30:11 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA26155; Sat, 23 Oct 93 09:25:42 PDT Message-Id: <9310231625.AA26155@dbeusee.us.oracle.com> Date: Sat, 23 Oct 93 09:25:42 PDT From: Don Beusee To: mcooper@usc.edu Subject: rdist output Cc: rdist-dev@usc.edu Mike, We need an option to tell rdist not to show special and cmdspecial (and probably notify) directives on stdout during rdist. rdist -q should not show them, but I also would like another option so that I can show the files updated without showing the ugly commands executed. I think a different message type would be appropriate. Regards, Don. From rouilj@cs.umb.edu Sat Oct 23 12:23:51 1993 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29299; Sat, 23 Oct 93 12:23:51 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA23520 (5.65c/IDA-1.4.4 for ); Sat, 23 Oct 1993 15:23:25 -0400 Message-Id: <199310231923.AA23520@cs.umb.edu> To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: rdist: pullfrom In-Reply-To: Your message of "Sat, 23 Oct 1993 09:16:49 PDT." <9310231616.AA26075@dbeusee.us.oracle.com> Date: Sat, 23 Oct 1993 15:23:24 -0400 From: "John P. Rouillard" In message <9310231616.AA26075@dbeusee.us.oracle.com>, Don Beusee writes: > Mike, > > I got a great idea for an rdist enhancement. A "pullfrom" directive. > Here's how it would work. Take this example: > > ${FILES} -> ${HOSTS} > pullfrom ${SRCHOST}; > install; > > The above would first pull ${FILES} from ${SRCHOST}, then install them on > ${HOSTS}. > > This has 2 GREAT features: > - we can use rdist to pull files instead of requiring the source > host to push them. > - we can pull from a source host then push (rdist) those files > to some other hosts. > > The pull should obviously use the same rdist mechanism (only update > neccessary files). The pullfrom should take the same options as > install. > > If ${HOSTS} is specified as "NOINSTALL", then no install (push) > should be done. > Example: > ${FILES} -> NOINSTALL > pullfrom {$SRCHOST}; > > What do you think? Just how do we get the files from the other host. Rdist requires rsh access in a single direction (I do it from more secure to less secure machines). With the pull mechanism the systems would have to be set up to allow rsh access bi-directionally. Not very good. Most pull systems (sup, and I think track) get around this problem by having the pull process authenticate to a running daemon on the server machine. Then the server daemon process controls file access etc. Rhost access just has too large a granularity to allow its use as a pull mechanism. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Sat Oct 23 16:06:34 1993 Return-Path: Received: from gatekeeper.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06307; Sat, 23 Oct 93 16:06:34 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA07764; Sat, 23 Oct 93 16:06:09 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00895; Sat, 23 Oct 93 16:01:39 PDT Message-Id: <9310232301.AA00895@dbeusee.us.oracle.com> Date: Sat, 23 Oct 93 16:01:39 PDT From: Don Beusee To: rouilj@cs.umb.edu Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu Pulling does not require priviledged access. You could use a public account for pulling stuff, like maybe ftp@host. If thats not acceptable, then rdist could be written so that its rdistd daemon listens on a port other than the rsh port and can do its own authentication. But for now, I think the rsh approach would be fine. Some sites do not want to give the secure host access to all its machines on the network. Such sites would prefer to pull rather than push. Pushing as root for instance, requires /.rhosts access to all machines being pushed to. Pulling does not. This is more secure. Remember that rdist must push as root in order to push to directories only writable by root, such as /usr. With a pull, the local root user can rdist from nonrootuser@srchost. There's nothing wrong with adding the flexibility and letting the site choose which approach they want to take depending on their needs. Regards, Don. From rouilj@cs.umb.edu Sat Oct 23 12:19:23 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA28605; Sat, 23 Oct 93 12:19:22 PDT Received: from cs.umb.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA29108; Sat, 23 Oct 93 12:23:32 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA23520 (5.65c/IDA-1.4.4 for ); Sat, 23 Oct 1993 15:23:25 -0400 Message-Id: <199310231923.AA23520@cs.umb.edu> To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: rdist: pullfrom In-Reply-To: Your message of "Sat, 23 Oct 1993 09:16:49 PDT." <9310231616.AA26075@dbeusee.us.oracle.com> Date: Sat, 23 Oct 1993 15:23:24 -0400 From: "John P. Rouillard" Status: R In message <9310231616.AA26075@dbeusee.us.oracle.com>, Don Beusee writes: > Mike, > > I got a great idea for an rdist enhancement. A "pullfrom" directive. > Here's how it would work. Take this example: > > ${FILES} -> ${HOSTS} > pullfrom ${SRCHOST}; > install; > > The above would first pull ${FILES} from ${SRCHOST}, then install them on > ${HOSTS}. > > This has 2 GREAT features: > - we can use rdist to pull files instead of requiring the source > host to push them. > - we can pull from a source host then push (rdist) those files > to some other hosts. > > The pull should obviously use the same rdist mechanism (only update > neccessary files). The pullfrom should take the same options as > install. > > If ${HOSTS} is specified as "NOINSTALL", then no install (push) > should be done. > Example: > ${FILES} -> NOINSTALL > pullfrom {$SRCHOST}; > > What do you think? Just how do we get the files from the other host. Rdist requires rsh access in a single direction (I do it from more secure to less secure machines). With the pull mechanism the systems would have to be set up to allow rsh access bi-directionally. Not very good. Most pull systems (sup, and I think track) get around this problem by having the pull process authenticate to a running daemon on the server machine. Then the server daemon process controls file access etc. Rhost access just has too large a granularity to allow its use as a pull mechanism. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From aad@dvorak.amd.com Sun Oct 24 10:31:43 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11438; Sun, 24 Oct 93 10:31:43 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA27139 (5.67a/IDA-1.5+AMD for ); Sun, 24 Oct 1993 10:31:06 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA01898 (5.67a/RELAY-IDA-1.2+AMD); Sun, 24 Oct 1993 10:31:05 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA04845; Sun, 24 Oct 93 12:31:05 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA18881; Sun, 24 Oct 93 12:31:10 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Sun, 24 Oct 1993 12:31:09 -0500 (CDT) Message-Id: Date: Sun, 24 Oct 1993 12:31:09 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rouilj@cs.umb.edu, Don Beusee Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310232301.AA00895@dbeusee.us.oracle.com> References: <9310232301.AA00895@dbeusee.us.oracle.com> >With a pull, the local root user can rdist from nonrootuser@srchost. True enough, but what about getting files from the remote host that aren't publically readable? ======================================================================8--< From dbeusee@us.oracle.com Sun Oct 24 11:11:43 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12440; Sun, 24 Oct 93 11:11:43 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA14081; Sun, 24 Oct 93 11:11:39 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10692; Sun, 24 Oct 93 11:07:10 PDT Message-Id: <9310241807.AA10692@dbeusee.us.oracle.com> Date: Sun, 24 Oct 93 11:07:10 PDT From: Don Beusee To: aad@lovecraft.amd.com, rouilj@cs.umb.edu Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu Obviously the site would make the files readable by the user rdist will use. No big deal. From aad@dvorak.amd.com Sun Oct 24 10:30:51 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA10415; Sun, 24 Oct 93 10:30:40 PDT Received: from amdext.amd.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA12997; Sun, 24 Oct 93 10:34:51 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA27139 (5.67a/IDA-1.5+AMD for ); Sun, 24 Oct 1993 10:31:06 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA01898 (5.67a/RELAY-IDA-1.2+AMD); Sun, 24 Oct 1993 10:31:05 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA04845; Sun, 24 Oct 93 12:31:05 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA18881; Sun, 24 Oct 93 12:31:10 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Sun, 24 Oct 1993 12:31:09 -0500 (CDT) Message-Id: Date: Sun, 24 Oct 1993 12:31:09 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rouilj@cs.umb.edu, Don Beusee Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310232301.AA00895@dbeusee.us.oracle.com> References: <9310232301.AA00895@dbeusee.us.oracle.com> Status: R >With a pull, the local root user can rdist from nonrootuser@srchost. True enough, but what about getting files from the remote host that aren't publically readable? ======================================================================8--< From rsalz@osf.org Mon Oct 25 06:48:37 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18095; Mon, 25 Oct 93 06:48:37 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06436; Mon, 25 Oct 93 09:48:29 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12233; Mon, 25 Oct 93 09:48:46 -0400 Date: Mon, 25 Oct 93 09:48:46 -0400 From: rsalz@osf.org Message-Id: <9310251348.AA12233@sulphur.osf.org> To: dbeusee@us.oracle.com Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu > Obviously the site would make the files readable by the user rdist will use. > No big deal. Really? You're gonna make /etc/passwd world readable? Gee, thanks! /r$ From aad@dvorak.amd.com Mon Oct 25 07:16:13 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19001; Mon, 25 Oct 93 07:16:13 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA03831 (5.67a/IDA-1.5+AMD for ); Mon, 25 Oct 1993 07:16:12 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA10512 (5.67a/RELAY-IDA-1.2+AMD); Mon, 25 Oct 1993 07:16:11 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA09680; Mon, 25 Oct 93 09:16:10 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA19598; Mon, 25 Oct 93 09:16:15 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 25 Oct 1993 09:16:14 -0500 (CDT) Message-Id: Date: Mon, 25 Oct 1993 09:16:14 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rouilj@cs.umb.edu, Don Beusee Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310241807.AA10692@dbeusee.us.oracle.com> References: <9310241807.AA10692@dbeusee.us.oracle.com> >Obviously the site would make the files readable by the user rdist will use. >No big deal Yes big deal, if you're disting something like op.access that really wants to be unreadable. ======================================================================8--< From mh1@irz.inf.tu-dresden.de Mon Oct 25 09:57:54 1993 Return-Path: Received: from irz301.inf.tu-dresden.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24984; Mon, 25 Oct 93 09:57:54 PDT Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA00846; Mon, 25 Oct 1993 17:55:57 +0100 Received: by irz209.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA01402; Mon, 25 Oct 1993 17:55:53 +0100 From: mh1@irz.inf.tu-dresden.de (Michael Hohmuth) Message-Id: <9310251655.AA01402@irz209.inf.tu-dresden.de> Subject: Re: rdist: pullfrom To: rdist-dev@usc.edu Date: Mon, 25 Oct 1993 17:55:51 +0100 (MET) In-Reply-To: from "Anthony A. Datri" at Oct 25, 93 09:16:14 am Reply-To: hohmuth@freia.inf.tu-dresden.de X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 > >Obviously the site would make the files readable by the user rdist will use. > >No big deal > > Yes big deal, if you're disting something like op.access that really > wants to be unreadable. I'd vote for implementing the feature. Extra authentication could be added later, but I think it's very useful even without it (i.e., just with rsh authentication). At this site, a pull feature would be of great use: Some institutes of this department want to share in software packages from others, but don't want to allow rsh access... Michael -- Internet: hohmuth@freia.inf.tu-dresden.de From dbeusee@us.oracle.com Mon Oct 25 13:23:40 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04788; Mon, 25 Oct 93 13:23:40 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA06264; Mon, 25 Oct 93 13:23:27 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA23919; Mon, 25 Oct 93 13:18:59 PDT Message-Id: <9310252018.AA23919@dbeusee.us.oracle.com> Date: Mon, 25 Oct 93 13:18:59 PDT From: Don Beusee To: rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu Did I say "world readable". No. I said readable by the user rdist will use. If a site wants to allow pulling /etc/passwd (which is world readable anyway) without making it world readable, the site will just chgrp it and list that one user as a member in the group. The .rhosts for that user controls which hosts may read it. From rsalz@osf.org Mon Oct 25 07:01:46 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20748; Mon, 25 Oct 93 07:01:34 PDT Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA04685; Mon, 25 Oct 93 07:05:56 PDT Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18095; Mon, 25 Oct 93 06:48:37 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06436; Mon, 25 Oct 93 09:48:29 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12233; Mon, 25 Oct 93 09:48:46 -0400 Date: Mon, 25 Oct 93 09:48:46 -0400 From: rsalz@osf.org Message-Id: <9310251348.AA12233@sulphur.osf.org> To: dbeusee@us Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu Status: R > Obviously the site would make the files readable by the user rdist will use. > No big deal. Really? You're gonna make /etc/passwd world readable? Gee, thanks! /r$ From rsalz@osf.org Mon Oct 25 13:25:31 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04925; Mon, 25 Oct 93 13:25:31 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA16583; Mon, 25 Oct 93 16:25:27 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA14282; Mon, 25 Oct 93 16:25:48 -0400 Date: Mon, 25 Oct 93 16:25:48 -0400 From: rsalz@osf.org Message-Id: <9310252025.AA14282@sulphur.osf.org> To: dbeusee@us.oracle.com, rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu You've perhaps narrowed the hole, but not closed it. Your pull scheme cannot send over owner-read-only files. From dbeusee@us.oracle.com Mon Oct 25 13:26:41 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04998; Mon, 25 Oct 93 13:26:41 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA06498; Mon, 25 Oct 93 13:26:26 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA23991; Mon, 25 Oct 93 13:21:58 PDT Message-Id: <9310252021.AA23991@dbeusee.us.oracle.com> Date: Mon, 25 Oct 93 13:21:58 PDT From: Don Beusee To: aad@lovecraft.amd.com, rouilj@cs.umb.edu Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu The .rhosts for the user rdist will use can control which users/hosts can pull it. So if you list "remhost root", then the security of the file is the same whether pulling it or pushing it. But the security of remhost is better, because it does not need to allow the srchost root access to the machine. From aad@dvorak.amd.com Mon Oct 25 07:16:20 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20851; Mon, 25 Oct 93 07:16:09 PDT Received: from amdext.amd.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA06461; Mon, 25 Oct 93 07:20:35 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA03831 (5.67a/IDA-1.5+AMD for ); Mon, 25 Oct 1993 07:16:12 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA10512 (5.67a/RELAY-IDA-1.2+AMD); Mon, 25 Oct 1993 07:16:11 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA09680; Mon, 25 Oct 93 09:16:10 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA19598; Mon, 25 Oct 93 09:16:15 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 25 Oct 1993 09:16:14 -0500 (CDT) Message-Id: Date: Mon, 25 Oct 1993 09:16:14 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rouilj@cs.umb.edu, Don Beusee Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310241807.AA10692@dbeusee.us.oracle.com> References: <9310241807.AA10692@dbeusee.us.oracle.com> Status: R >Obviously the site would make the files readable by the user rdist will use. >No big deal Yes big deal, if you're disting something like op.access that really wants to be unreadable. ======================================================================8--< From aad@dvorak.amd.com Mon Oct 25 14:04:04 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06676; Mon, 25 Oct 93 14:04:04 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA03064 (5.67a/IDA-1.5+AMD for ); Mon, 25 Oct 1993 14:03:56 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA20945 (5.67a/RELAY-IDA-1.2+AMD); Mon, 25 Oct 1993 14:03:55 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA14345; Mon, 25 Oct 93 16:03:54 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA20534; Mon, 25 Oct 93 16:03:59 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 25 Oct 1993 16:03:58 -0500 (CDT) Message-Id: Date: Mon, 25 Oct 1993 16:03:58 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310252018.AA23919@dbeusee.us.oracle.com> References: <9310252018.AA23919@dbeusee.us.oracle.com> >If a site wants to allow pulling /etc/passwd (which is world readable anyway) On your machine and mine, but some sites/os's do various sorts of shadowing. ======================================================================8--< From dbeusee@us.oracle.com Mon Oct 25 14:26:15 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07707; Mon, 25 Oct 93 14:26:15 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA11854; Mon, 25 Oct 93 14:26:06 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA24613; Mon, 25 Oct 93 14:21:37 PDT Message-Id: <9310252121.AA24613@dbeusee.us.oracle.com> Date: Mon, 25 Oct 93 14:21:37 PDT From: Don Beusee To: rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu The site will setup the rdist to work, believe me. If the files must be only owner readable, then they will setup the rdist to run as the owner. But there is no reason why the file cannot be group-readable and the rdist user included in that group. Trust me, the pull rdist can be made just as secure (more secure in fact) than the push rdist. How secure is up to the site that implements it. The rshd security is all you need. No new daemon is required, since the ~srcuser/.rhosts file contains "pullhost pulluser" that can get into the srcuser@srchost and pull the files srcuser has read access to. The security of the files on srchost is up to the site. Use your imagination. If you want some hosts to be able to pull more stuff, than setup a srcuserpriv on srchost and put those hosts/users in the ~srcuserpriv/.rhosts file. Again, use your imagination. Obviously, if a site does not wish to allow pulling, those sites don't have to do anything. But there are sites out there that want it. All we need is the capability in rdist to do pulls. This should not be too hard to implement. Regards, Don. From rsalz@osf.org Mon Oct 25 13:26:19 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA24016; Mon, 25 Oct 93 13:26:17 PDT Received: from postman.osf.org by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA06804; Mon, 25 Oct 93 13:30:40 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA16583; Mon, 25 Oct 93 16:25:27 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA14282; Mon, 25 Oct 93 16:25:48 -0400 Date: Mon, 25 Oct 93 16:25:48 -0400 From: rsalz@osf.org Message-Id: <9310252025.AA14282@sulphur.osf.org> To: dbeusee@us, rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu Status: R You've perhaps narrowed the hole, but not closed it. Your pull scheme cannot send over owner-read-only files. From dbeusee@us.oracle.com Mon Oct 25 14:31:46 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07984; Mon, 25 Oct 93 14:31:46 PDT Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA12113; Mon, 25 Oct 93 14:31:26 PDT Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA24635; Mon, 25 Oct 93 14:26:57 PDT Message-Id: <9310252126.AA24635@dbeusee.us.oracle.com> Date: Mon, 25 Oct 93 14:26:57 PDT From: Don Beusee To: aad@lovecraft.amd.com, rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu I think /etc/passwd MUST be readable for things like ls to work. All sorts of programs do getpwent(), etc. /etc/shadow on a lot of platforms contain the passwords (which is not world-readable). If you want a machine to copy your passwd file, put: pullhost root in the ~srcuser/.rhosts file on srchost and make /etc/passwd group-readable by an rdist group and put srcuser in that group. Now /etc/passwd is just as secure as its always been. Regards, Don. From aad@dvorak.amd.com Mon Oct 25 14:21:45 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA24617; Mon, 25 Oct 93 14:21:44 PDT Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA11859; Mon, 25 Oct 93 14:26:10 PDT Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06676; Mon, 25 Oct 93 14:04:04 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA03064 (5.67a/IDA-1.5+AMD for ); Mon, 25 Oct 1993 14:03:56 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA20945 (5.67a/RELAY-IDA-1.2+AMD); Mon, 25 Oct 1993 14:03:55 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA14345; Mon, 25 Oct 93 16:03:54 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA20534; Mon, 25 Oct 93 16:03:59 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 25 Oct 1993 16:03:58 -0500 (CDT) Message-Id: Date: Mon, 25 Oct 1993 16:03:58 -0500 (CDT) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rsalz@osf.org Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu In-Reply-To: <9310252018.AA23919@dbeusee.us.oracle.com> References: <9310252018.AA23919@dbeusee.us.oracle.com> Status: R >If a site wants to allow pulling /etc/passwd (which is world readable anyway) On your machine and mine, but some sites/os's do various sorts of shadowing. ======================================================================8--< From rsalz@osf.org Tue Oct 26 05:27:51 1993 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10672; Tue, 26 Oct 93 05:27:51 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06700; Tue, 26 Oct 93 08:27:49 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA15170; Tue, 26 Oct 93 08:28:09 -0400 Date: Tue, 26 Oct 93 08:28:09 -0400 From: rsalz@osf.org Message-Id: <9310261228.AA15170@sulphur.osf.org> To: dbeusee@us.oracle.com Subject: Re: rdist: pullfrom Cc: rdist-dev@usc.edu > Trust me, the pull rdist can be made just as secure (more secure in fact) than > the push rdist. I have not thought about it a great deal, but unless you are able to do multiple su's on the recipient machine I don't quite see how this is so. "Trust me." Yeah, sure. From wls@astro.UMD.EDU Tue Oct 26 07:36:02 1993 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14348; Tue, 26 Oct 93 07:36:02 PDT Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA02080; Tue, 26 Oct 1993 10:36:00 -0400 Date: Tue, 26 Oct 1993 10:36:00 -0400 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199310261436.AA02080@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: rdist: pullfrom Add my vote for the feature. I don't understand the objections of rsalz@osf.org. It still seems to me that the option to pull from some non-root uid is more secure than a push by root. The push by root has always seemed to me a giant security hole. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From mcooper@ucs.usc.edu Tue Oct 26 10:29:29 1993 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21737; Tue, 26 Oct 93 10:29:29 PDT Received: by acamar.usc.edu (5.0/SMI-4.1+ucs-3.6) id AA10553; Tue, 26 Oct 93 10:29:25 PDT Sender: "Michael A. Cooper" Date: Tue, 26 Oct 93 10:29:24 PDT From: Michael A. Cooper Reply-To: mcooper@usc.edu To: Don Beusee Cc: rouilj@cs.umb.edu, rdist-dev@usc.edu Subject: Re: rdist: pullfrom In-Reply-To: Your message of Sat, 23 Oct 93 16:01:39 PDT Message-Id: Content-Length: 435 I think the "pullfrom" idea is fine. I think implementing it in the current rdist code will be ugly and will require a very large shoe horn. I'm getting married next month and so I'm pretty busy. I hope to get out a "production" version of 6.1 out by January. I'm not going to add any new features to 6.1. After 6.1 I want to give some serious thought to a total re-write before trying to wedge in additional funtionality. mike From dbeusee@us.oracle.com Mon Nov 1 07:45:57 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01121; Mon, 1 Nov 93 07:45:57 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA25134; Mon, 1 Nov 93 07:45:56 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20883; Mon, 1 Nov 93 07:41:31 PST Message-Id: <9311011541.AA20883@dbeusee.us.oracle.com> Date: Mon, 1 Nov 93 07:41:31 PST From: Don Beusee To: mcooper@usc.edu Subject: rdist bugs Cc: rdist-dev@usc.edu I have 2 problems today with 61b2: 1. -D does not give me any debug messages 2. Get an error if I have 2 cmdspecial directives: mailseq: ./rmoldfiles: updating mailseq: cmdspecial "cd /local/PostScript; make" mailseq: `psp' is up to date. mailseq: cmdspecial "/local/PostScript/rmoldfiles" mailseq: REMOTE ERROR: server: unknown command 'F.' mailseq: updating of mailseq finished Any ideas? #2 happens with 61b1 also. But #1 is new to 61b2. Regards, Don. From pwaleski@us Thu Mar 19 10:54:28 1992 Received: from wrpyr.us.oracle.com by dbeusee.us.oracle.com (5.59.10/37.3) id AA27613; Thu, 19 Mar 92 10:54:27 PST Received: by wrpyr.us.oracle.com (5.59.11/37.7) id AA29899; Thu, 19 Mar 92 10:46:30 PST Message-Id: <9203191846.AA29899@wrpyr.us.oracle.com> Date: Thu, 19 Mar 92 10:46:30 PST From: "Paul Waleski " To: RHADDICK@us, RCHILDER@us, PMCELROY@us, PMABON@us, MGLASS@us, JHANLEY@us, DBEUSEE@us, BCOE@us Subject: pictures for new badges Original-To: unxadm Status: RO I just received a call from Pat, she tells me that new pictures for badges are required and that they can be taken today or tomorrow from 11-12. Apparently the new badges will allow easier access when moving equipment. Regards, Paul ------------------------------------------------------------------------------ Oracle Data Center - 400 Oracle Parkway, 4th floor, office 486, (415)506-2376 Internet: pwaleski@us.oracle.com "What has the computer done for you lately?" ------------------------------------------------------------------------------ From dbeusee@us.oracle.com Mon Nov 1 08:34:09 1993 Return-Path: Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02760; Mon, 1 Nov 93 08:34:09 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA28527; Mon, 1 Nov 93 08:34:02 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21271; Mon, 1 Nov 93 08:29:37 PST Message-Id: <9311011629.AA21271@dbeusee.us.oracle.com> Date: Mon, 1 Nov 93 08:29:37 PST From: Don Beusee To: mcooper@usc.edu Subject: Re: rdist bugs Cc: rdist-dev@usc.edu Ooops - I did not mean to forward that note. Please ignore it - sorry for the confusion. From dbeusee@us Mon Nov 1 08:11:06 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA21154; Mon, 1 Nov 93 08:11:05 PST Received: from usc.edu by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA27160; Mon, 1 Nov 93 08:15:25 PST Received: from gatekeeper.oracle.com (gatekeeper.us.oracle.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01121; Mon, 1 Nov 93 07:45:57 PST Received: from dbeusee.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA25134; Mon, 1 Nov 93 07:45:56 PST Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20883; Mon, 1 Nov 93 07:41:31 PST Message-Id: <9311011541.AA20883@dbeusee.us.oracle.com> Date: Mon, 1 Nov 93 07:41:31 PST From: Don Beusee To: mcooper@usc.edu Subject: rdist bugs Cc: rdist-dev@usc.edu Status: R I have 2 problems today with 61b2: 1. -D does not give me any debug messages 2. Get an error if I have 2 cmdspecial directives: mailseq: ./rmoldfiles: updating mailseq: cmdspecial "cd /local/PostScript; make" mailseq: `psp' is up to date. mailseq: cmdspecial "/local/PostScript/rmoldfiles" mailseq: REMOTE ERROR: server: unknown command 'F.' mailseq: updating of mailseq finished Any ideas? #2 happens with 61b1 also. But #1 is new to 61b2. Regards, Don. >From pwaleski@us Thu Mar 19 10:54:28 1992 Received: from wrpyr.us.oracle.com by dbeusee.us.oracle.com (5.59.10/37.3) id AA27613; Thu, 19 Mar 92 10:54:27 PST Received: by wrpyr.us.oracle.com (5.59.11/37.7) id AA29899; Thu, 19 Mar 92 10:46:30 PST Message-Id: <9203191846.AA29899@wrpyr.us.oracle.com> Date: Thu, 19 Mar 92 10:46:30 PST From: "Paul Waleski " To: RHADDICK@us, RCHILDER@us, PMCELROY@us, PMABON@us, MGLASS@us, JHANLEY@us, DBEUSEE@us, BCOE@us Subject: pictures for new badges Original-To: unxadm Status: RO I just received a call from Pat, she tells me that new pictures for badges are required and that they can be taken today or tomorrow from 11-12. Apparently the new badges will allow easier access when moving equipment. Regards, Paul ------------------------------------------------------------------------------ Oracle Data Center - 400 Oracle Parkway, 4th floor, office 486, (415)506-2376 Internet: pwaleski@us.oracle.com "What has the computer done for you lately?" ------------------------------------------------------------------------------ From tmoore@fievel.DaytonOH.NCR.COM Thu Nov 11 08:03:08 1993 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18772; Thu, 11 Nov 93 08:03:08 PST Message-Id: <9311111603.AA18772@usc.edu> Subject: Problems with linked files To: rdist-dev@usc.edu (Rdist Development Group) Date: Thu, 11 Nov 1993 11:03:03 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 511 Given a file structure on the source host of /home/user/application/directory1/file1 /home/user/application/directory2/file1 (link to previous) running rdist in the "application" directory and with a distfile of ( directory1 directory2 ) -> testhost install /tmp ; installs file1 as /tmp/directory1/file1 (good) but tries to link /tmp/file1 to /tmp/directory2/file1 (bad) REMOTE ERROR: /tmp/directory2/file1: cannot link to /tmp/file1: No such file or directory Any ideas why? -- Tom Moore From dbeusee@us.oracle.com Thu Nov 11 08:45:17 1993 Return-Path: Received: from gatekeeper.us.oracle.com (GATEKEEPER.ORACLE.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20545; Thu, 11 Nov 93 08:45:17 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id IAA03113; Thu, 11 Nov 1993 08:45:10 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09424; Thu, 11 Nov 93 08:44:55 PST Message-Id: <9311111644.AA09424@dbeusee.us.oracle.com> Date: Thu, 11 Nov 93 08:44:55 PST From: Don Beusee To: rdist-dev@usc.edu, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Problems with linked files What version are you running? If < 6.1b2, did you apply my patches? From tmoore@fievel.DaytonOH.NCR.COM Thu Nov 11 08:32:30 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09273; Thu, 11 Nov 93 08:32:19 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id IAA02369; Thu, 11 Nov 1993 08:32:32 -0800 Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18772; Thu, 11 Nov 93 08:03:08 PST Message-Id: <9311111603.AA18772@usc.edu> Subject: Problems with linked files To: rdist-dev@usc.edu (Rdist Development Group) Date: Thu, 11 Nov 1993 11:03:03 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 511 Status: R Given a file structure on the source host of /home/user/application/directory1/file1 /home/user/application/directory2/file1 (link to previous) running rdist in the "application" directory and with a distfile of ( directory1 directory2 ) -> testhost install /tmp ; installs file1 as /tmp/directory1/file1 (good) but tries to link /tmp/file1 to /tmp/directory2/file1 (bad) REMOTE ERROR: /tmp/directory2/file1: cannot link to /tmp/file1: No such file or directory Any ideas why? -- Tom Moore From aad@dvorak.amd.com Tue Nov 16 18:00:45 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20878; Tue, 16 Nov 93 18:00:45 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA20718 (5.67a/IDA-1.5+AMD for ); Tue, 16 Nov 1993 18:00:44 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA24409 (5.67a/IDA-1.5+AMD for ); Tue, 16 Nov 1993 18:00:43 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA02214; Tue, 16 Nov 93 20:00:43 CST Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA14679; Tue, 16 Nov 93 20:00:53 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 16 Nov 1993 20:00:52 -0600 (CST) Message-Id: <0guMLImXhG4BMseGZ7@lovecraft.amd.com> Date: Tue, 16 Nov 1993 20:00:52 -0600 (CST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: I'm just not getting something Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 disting from a Sun running 4.1.2 to an HP running 9.0.1. There are files under /usr/local/bin.hp9000s700/gnumacs19.19 on the Sun, and I'm trying to dist them to an HP with: gnumacs: ( /usr/local/bin.hp9000s700/gnumacs.19.19 ) -> ( ${GNUMACS19} ) & ( ${HP700} ) install -ochknfs /usr/local/bin; cmdspecial "if [ ! -x /usr/local/bin/emacs ]; then rm -f /usr/local/bin/emacs ; ln -s gnumacs.19.19/emacs /usr/local/bin/emacs ; fi;"; For some unknown reason, though, the files under gnumacs19.19 get pushed to /usr/local/bin on the remote machine, instead of /usr/local/bin/gnumacs.19.19 being created and populated. What am I missing? ======================================================================8--< From dbeusee@us.oracle.com Wed Nov 17 02:09:56 1993 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09260; Wed, 17 Nov 93 02:09:56 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id CAA29128; Wed, 17 Nov 1993 02:09:52 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA00531; Wed, 17 Nov 93 02:09:37 PST Message-Id: <9311171009.AA00531@dbeusee.us.oracle.com> Date: Wed, 17 Nov 93 02:09:37 PST From: Don Beusee To: aad@lovecraft.amd.com Subject: Re: I'm just not getting something Cc: rdist-dev@usc.edu Change: install -ochknfs /usr/local/bin; To: install -ochknfs /usr/local/bin/gnumacs.19.19; It is a feature that when you rdist one directory to another, its contents are installed into the destination directory (in the above case, rdist does not know that /usr/local/bin is a directory at the time it determines what the destination is). Or you could do: install -ochknfs /usr/local/bin/.; This tells rdist that the destination is a directory, and therefore, it will put gnumacs.19.19 in there. Regards, Don. From aad@dvorak.amd.com Wed Nov 17 00:43:39 1993 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA29522; Wed, 17 Nov 93 00:43:33 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id AAA21414; Wed, 17 Nov 1993 00:43:32 -0800 Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20878; Tue, 16 Nov 93 18:00:45 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA20718 (5.67a/IDA-1.5+AMD for ); Tue, 16 Nov 1993 18:00:44 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA24409 (5.67a/IDA-1.5+AMD for ); Tue, 16 Nov 1993 18:00:43 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA02214; Tue, 16 Nov 93 20:00:43 CST Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA14679; Tue, 16 Nov 93 20:00:53 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 16 Nov 1993 20:00:52 -0600 (CST) Message-Id: <0guMLImXhG4BMseGZ7@lovecraft.amd.com> Date: Tue, 16 Nov 1993 20:00:52 -0600 (CST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: I'm just not getting something Status: R Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 disting from a Sun running 4.1.2 to an HP running 9.0.1. There are files under /usr/local/bin.hp9000s700/gnumacs19.19 on the Sun, and I'm trying to dist them to an HP with: gnumacs: ( /usr/local/bin.hp9000s700/gnumacs.19.19 ) -> ( ${GNUMACS19} ) & ( ${HP700} ) install -ochknfs /usr/local/bin; cmdspecial "if [ ! -x /usr/local/bin/emacs ]; then rm -f /usr/local/bin/emacs ; ln -s gnumacs.19.19/emacs /usr/local/bin/emacs ; fi;"; For some unknown reason, though, the files under gnumacs19.19 get pushed to /usr/local/bin on the remote machine, instead of /usr/local/bin/gnumacs.19.19 being created and populated. What am I missing? ======================================================================8--< From john@WPI.EDU Thu Dec 2 08:43:34 1993 Return-Path: Received: from bigboote.WPI.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08548; Thu, 2 Dec 93 08:43:34 PST Received: from sekrit.WPI.EDU (john@sekrit.WPI.EDU [130.215.24.6]) by bigboote.WPI.EDU (8.6.5.Beta1/8.6) with ESMTP id LAA23714 for ; Thu, 2 Dec 1993 11:43:30 -0500 From: John Stoffel Received: from localhost (john@localhost) by sekrit.WPI.EDU (8.6.5.Beta1/8.6) id LAA18462; Thu, 2 Dec 1993 11:43:27 -0500 Date: Thu, 2 Dec 1993 11:43:27 -0500 Message-Id: <199312021643.LAA18462@sekrit.WPI.EDU> To: rdist-dev@usc.edu Subject: Possible bug with numcheckowner options We've been using rdist 6.1.2, with Don Beusee's patches, for quite a while now and we're really happy with it. We are running with Ultrix 4.4 on a mix of various DECstations. Mostly 5000/50 to 5000/240, 5000/133, and 5000/25. We have run into a problem that has pointed up either a deficiency with our setup, or two possible bugs in rdist itself. Our uucp setup for some reason has two entries in the passwd file, uucp and uucpa, with the same uid. This has to be for some reason. Rdist doesn't like this and continually sends over those few files each night. They're aren't big, but it is noise we could do without. So I poked around the code and found the two options for numchkowner and numchkgroup, which I thought would be perfect for getting rid of the name compare problems. And it did, but now it fails on negative uids. I traced the problem to the macro isdigit() in the stdio.h file, and rather than change that, I just added a check for '-' in the client.c part of the system so it would accept negative numbers. Here is a simple patch which seems to work for me. > diff client.c.orig client.c 837c837,838 < while (*owner && !isdigit(*owner)) --- > while (*owner && (!isdigit(*owner) && (*owner > != '-'))) 861c862,863 < while (*group && !isdigit(*group)) --- > while (*group && (!isdigit(*group) && (*owner > != '-'))) From john@WPI.EDU Mon Dec 6 08:22:18 1993 Return-Path: Received: from bigboote.WPI.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24881; Mon, 6 Dec 93 08:22:18 PST Received: from sekrit.WPI.EDU (john@sekrit.WPI.EDU [130.215.24.6]) by bigboote.WPI.EDU (8.6.5.Beta4/8.6) with ESMTP id LAA02743; Mon, 6 Dec 1993 11:22:09 -0500 From: John Stoffel Received: from localhost (john@localhost) by sekrit.WPI.EDU (8.6.5.Beta4/8.6) id LAA01951; Mon, 6 Dec 1993 11:22:08 -0500 Date: Mon, 6 Dec 1993 11:22:08 -0500 Message-Id: <199312061622.LAA01951@sekrit.WPI.EDU> To: John Stoffel Cc: rdist-dev@usc.edu Subject: Possible bug with numcheckowner options In-Reply-To: <199312021643.LAA18462@sekrit.WPI.EDU> References: <199312021643.LAA18462@sekrit.WPI.EDU> Oops. I just discovered a bug in the patch I sent out to take care of negative owner and group numbers. Here's the fixed patch that works correctly. > diff client.c.orig client.c 837c837,838 < while (*owner && !isdigit(*owner)) --- > while (*owner && (!isdigit(*owner) && (*owner > != '-'))) 861c862,863 < while (*group && !isdigit(*group)) --- > while (*group && (!isdigit(*group) && (*group > != '-'))) From anthony.datri@amd.com Sun Dec 12 21:40:03 1993 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28542; Sun, 12 Dec 93 21:40:03 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA28668 (5.67a/IDA-1.5+AMD for ); Sun, 12 Dec 1993 21:40:02 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA00625 (5.67a/IDA-1.5+AMD for ); Sun, 12 Dec 1993 21:40:01 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA25118; Sun, 12 Dec 93 23:40:00 CST Received: by lovecraft.amd.com (4.1/AMDC-1.18) id AA05473; Sun, 12 Dec 93 23:40:15 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Sun, 12 Dec 1993 23:40:15 -0600 (CST) Message-Id: Date: Sun, 12 Dec 1993 23:40:15 -0600 (CST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: gratutitous "startup for " messages I found that 6.1.b2's rdistd seems to *always* syslog the "startup for" message. Here's my attempt at a patch to fix that: *** server.c.fcs Sun Dec 12 23:15:04 1993 --- server.c Sun Dec 12 23:39:41 1993 *************** *** 1183,1189 **** */ if (!fromhost) { fromhost = strdup(cp); ! message(MT_SYSLOG, "startup for %s", fromhost); #if defined(SETARGS) setproctitle("serving %s", cp); #endif /* SETARGS */ --- 1183,1190 ---- */ if (!fromhost) { fromhost = strdup(cp); ! /* message(MT_SYSLOG, "startup for %s", fromhost);*/ ! debugmsg(DM_MISC, "startup for %s", fromhost); #if defined(SETARGS) setproctitle("serving %s", cp); #endif /* SETARGS */ ======================================================================8--< From erickson@binky.ICS.UCI.EDU Thu Dec 23 05:39:59 1993 Return-Path: Received: from paris.ics.uci.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22915; Thu, 23 Dec 93 05:39:59 PST Received: from binky.ics.uci.edu by paris.ics.uci.edu id aa24269; 23 Dec 93 5:39 PST To: rdist-dev@binky.ICS.UCI.EDU Subject: passing vars Date: Thu, 23 Dec 1993 05:39:56 -0800 From: Scott Erickson Message-Id: <9312230539.aa24269@paris.ics.uci.edu> Version 6.1beta.2 - Protocol Version 6, Release 6.1beta, Patch level 2 MACH = Sun IPX OS = SunOS 5.2 I'm having trouble sending vars to rdist. For example, the following lines in a /bin/sh script: HOSTS="@sun4_usr_servers @sun3_usr_servers" rdist -d "HOSTS=($HOSTS)" will fail with "@sun3_usr_servers: no target in distfile" I've tried various ways of quoting the HOSTS var with no luck. I'd appreciate someone sending me the proper way to quote this. The only other workaround I know of is to "generate" a distfile and pipe it into rdist. /se University of California Irvine | 714/856-4035 Information and Computer Science Department | erickson@ics.uci.edu UNIX Support Group | From dbeusee@us.oracle.com Fri Jan 21 16:29:31 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19483; Fri, 21 Jan 94 16:29:31 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id QAA00652; Fri, 21 Jan 1994 16:29:30 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA26729; Fri, 21 Jan 94 16:28:00 PST Message-Id: <9401220028.AA26729@dbeusee.us.oracle.com> Date: Fri, 21 Jan 94 16:28:00 PST From: Don Beusee To: bcoe@us.oracle.com Subject: Re: "printer" package Cc: mcooper@usc.edu, rdist-dev@usc.edu Interesting. Rdist -n does not look at the exception list. They are not actually rdist'd to the system, but the -n option lists it anyway. I think this is a rdist bug. install -o condense.c /usr/local/bin/. install -o land.c /usr/local/bin/. install -o land.old.c /usr/local/bin/. install -o landnorm.c /usr/local/bin/. install -o landnorm.old.c /usr/local/bin/. install -o landstat.c /usr/local/bin/. install -o landwide.c /usr/local/bin/. install -o landwide.old.c /usr/local/bin/. install -o landwrap.c /usr/local/bin/. install -o landwrap.old.c /usr/local/bin/. install -o lis50.c /usr/local/bin/. install -o lpf.c /usr/local/bin/. install -o lpfnopg.c /usr/local/bin/. install -o pitch.c /usr/local/bin/. install -o widewrap.c /usr/local/bin/. Here's the distfile: B=/usr/local/bin L=/usr/local/lib all=(*.c $B/lis50.sh $B/pron $B/proff) ${all} -> ${HOSTS} install $B/.; special *.c "cd /usr/local/bin; f=`basename $FILE .c`;cc -o $f $FILE;chmod 755 $f"; special lpf*.c "cd /usr/local/bin; mv `basename $FILE .c` ../lib; cd /usr/lib; rm -f `basename $FILE .c`; ln -s /usr/local/lib/`basename $FILE .c` `basename $FILE .c`"; special *.c "rm -f /usr/local/bin/$FILE"; except_pat old\\\.c; Comments? From bcoe@us Fri Jan 21 14:16:51 1994 Received: from prodseq2.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA25385; Fri, 21 Jan 94 14:16:48 PST Received: by prodseq2.us.oracle.com (Oracle 1.12/37.7) id AA04694; Fri, 21 Jan 94 14:11:48 PST Message-Id: <9401212211.AA04694@prodseq2.us.oracle.com> Date: Fri, 21 Jan 94 14:11:48 PST From: Bruce C. Coe To: dbeusee@us Subject: "printer" package Status: R Also, if you can remove those .old's from the "printer" package that would be good. Thanks. - BC From mcooper@ucs.usc.edu Mon Feb 7 13:31:32 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07192; Mon, 7 Feb 94 13:31:32 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id NAA10807 for rdist-dev@usc.edu; Mon, 7 Feb 1994 13:31:31 -0800 Sender: "Michael A. Cooper" Date: Mon, 7 Feb 94 13:31:31 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: Which HPUX need -lPW Message-Id: A number of people have sent me conflicting updates to the rdist 6.1b? config/mf.hpux file. The conflict is that some HPUX versions apparantly need -lPW and some do not and don't appear to have that library. Would everybody running rdist 6.1 on an HPUX system please let me know what HPUX version you are running, if -lPW exists on that OS, and if rdist needs it. Thanks. mike From neal@ctd.comsat.com Mon Feb 7 13:44:32 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07794; Mon, 7 Feb 94 13:44:32 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pTdks-0002fOC; Mon, 7 Feb 94 16:44 EST Message-Id: Date: Mon, 7 Feb 94 16:44 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist-dev@usc.edu Subject: Which HPUX need -lPW In-Reply-To: References: I don't think this is hpux version dependent. As I recall -lPW is used to get alloca(). If you compile with gcc you don't need this because alloca is builtin. If any of this doesn't sound right let me know and I'll check - this is just from memory. From mcooper@ucs.usc.edu Tue Feb 8 10:51:34 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19697; Tue, 8 Feb 94 10:51:34 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id KAA19617; Tue, 8 Feb 1994 10:51:26 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 10:51:26 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Marc@Synergytics.Com Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Wed, 29 Sep 93 10:41:35 +0100 Message-Id: > Hi - > > I have found that I needed the following changes to run on SVR4.0 (Dell i486) > and SVR4.2 (NEC r4400). NOTE that I did NOT use #if's everyplace that I should > have, so do not consider this a clean patch... > It looks like you are trying to make rdist work correctly for normal (non-root) users under SVR4. I've fixed this by other means in the next release. Also, running rdistd setuid root is not advisible. It was never intended to be setuid root and probably contains security holes when run as such. mike From marc@synergy.Synergytics.Com Tue Feb 8 11:00:32 1994 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20065; Tue, 8 Feb 94 11:00:32 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id OAA29409; Tue, 8 Feb 1994 14:00:18 -0500 Message-Id: <199402081900.OAA29409@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 10:51:26 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 14:00:17 -0500 From: Marc Evans - Contract Software Hacker > > Hi - > > > > I have found that I needed the following changes to run on SVR4.0 (Dell i486) > > and SVR4.2 (NEC r4400). NOTE that I did NOT use #if's everyplace that I should > > have, so do not consider this a clean patch... > > > > It looks like you are trying to make rdist work correctly for normal > (non-root) users under SVR4. I've fixed this by other means in the > next release. Also, running rdistd setuid root is not advisible. > It was never intended to be setuid root and probably contains security > holes when run as such. Yes, you are correct in that I am trying to make rdist work correctly for non-root users under SVR4. You are also correct that there is great concern about security when havign to run SUID=root. I feel I must ask how you manage to get non-root users (of ANY OS, not just SVR4) to work properly without SUID=root? The key seems to be in the chown() function, which as I understand is only permitted to be called by the user root. In addition, the code is designed to consider the file out-of-date if the UID's don't match (unless the invoker explicitely overrides this test)... Can you possibly explain (without taking too much of your time) how you achieved your changes with respect to these observations? Thanks - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From mcooper@ucs.usc.edu Tue Feb 8 11:26:49 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21243; Tue, 8 Feb 94 11:26:49 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id LAA20050; Tue, 8 Feb 1994 11:26:44 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 11:26:43 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Marc@Synergytics.Com Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Tue, 08 Feb 1994 14:00:17 -0500 Message-Id: The rdist program needs to be setuid root. The rdistd (server) should not be setuid root. Your patch made rdistd setuid root among other things. mike From marc@synergy.Synergytics.Com Tue Feb 8 11:36:40 1994 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21654; Tue, 8 Feb 94 11:36:40 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id OAA29510; Tue, 8 Feb 1994 14:36:28 -0500 Message-Id: <199402081936.OAA29510@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 11:26:43 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 14:36:27 -0500 From: Marc Evans - Contract Software Hacker > The rdist program needs to be setuid root. The rdistd (server) should not > be setuid root. Your patch made rdistd setuid root among other things. Yeah... I must be missing something obvious to others, I guess... As I use it, rdist works using a push model, e.g., the application invoked by the user is the client and the server is on the remote end, having files pushed to it that are older then those on the client end. Because of this relationship, my experience has been that the client should not be SUID=root (unless you wish the local user to be able to push files they don't have access to normally), but rather the server does. This is because the server is the *thing* which is writing files, and most importantly, setting owner, group and access-mode. If the server isn't run SUID=root, it fails in calls to chown. So, is my picture of what is happening here really busted? The only way I can see that it would be is if the model is "pull" and not "push"... Please correct my vision 8-) Thanks again - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From mcooper@ucs.usc.edu Tue Feb 8 12:58:44 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25885; Tue, 8 Feb 94 12:58:44 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id MAA20729; Tue, 8 Feb 1994 12:58:40 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 12:58:39 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Marc@Synergytics.Com Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Tue, 08 Feb 1994 14:36:27 -0500 Message-Id: Rdist works just like rsh. In fact, it uses rshd to connect to on the remote host. If you run rdist on the local host as root, it runs as root on the remote host. If you run rdist as a normal user, it runs as that user on the remote host (provided .rhosts access is ok). The only reason the rdist (client) programs needs to be setuid is to be able to bind to the (privelged) rsh port on the remote host. mike From dbeusee@us.oracle.com Tue Feb 8 13:05:57 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26251; Tue, 8 Feb 94 13:05:57 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA28300; Tue, 8 Feb 1994 13:05:56 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07236; Tue, 8 Feb 94 13:04:07 PST Message-Id: <9402082104.AA07236@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 13:04:07 PST From: Don Beusee To: mcooper@usc.edu, neal@ctd.comsat.com Subject: Re: Which HPUX need -lPW Cc: rdist-dev@usc.edu I support rdist on hpux and I don't need -lPW. From neal@ctd.comsat.com Mon Feb 7 14:07:40 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22695; Mon, 7 Feb 94 14:07:39 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA00665; Mon, 7 Feb 1994 14:09:17 -0800 Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07794; Mon, 7 Feb 94 13:44:32 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pTdks-0002fOC; Mon, 7 Feb 94 16:44 EST Message-Id: Date: Mon, 7 Feb 94 16:44 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist-dev@usc.edu Subject: Which HPUX need -lPW In-Reply-To: References: Status: R I don't think this is hpux version dependent. As I recall -lPW is used to get alloca(). If you compile with gcc you don't need this because alloca is builtin. If any of this doesn't sound right let me know and I'll check - this is just from memory. From dbeusee@us.oracle.com Tue Feb 8 13:07:54 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26345; Tue, 8 Feb 94 13:07:54 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA28387; Tue, 8 Feb 1994 13:07:53 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07251; Tue, 8 Feb 94 13:06:03 PST Message-Id: <9402082106.AA07251@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 13:06:03 PST From: Don Beusee To: mcooper@usc.edu, rdist-dev@usc.edu Subject: Re: Which HPUX need -lPW My uname -a reports: HP-UX prodhp1 A.09.04 U 9000/890 848206141 unlimited-user license And I do NOT need -lPW. From mcooper@skat.usc.edu Mon Feb 7 13:55:45 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22573; Mon, 7 Feb 94 13:55:45 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA29595; Mon, 7 Feb 1994 13:57:27 -0800 Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07192; Mon, 7 Feb 94 13:31:32 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id NAA10807 for rdist-dev@usc.edu; Mon, 7 Feb 1994 13:31:31 -0800 Sender: "Michael A. Cooper" Date: Mon, 7 Feb 94 13:31:31 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: Which HPUX need -lPW Message-Id: Status: R A number of people have sent me conflicting updates to the rdist 6.1b? config/mf.hpux file. The conflict is that some HPUX versions apparantly need -lPW and some do not and don't appear to have that library. Would everybody running rdist 6.1 on an HPUX system please let me know what HPUX version you are running, if -lPW exists on that OS, and if rdist needs it. Thanks. mike From neal@ctd.comsat.com Tue Feb 8 13:12:31 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26501; Tue, 8 Feb 94 13:12:31 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pTzjG-0002fOC; Tue, 8 Feb 94 16:12 EST Message-Id: Date: Tue, 8 Feb 94 16:12 EST From: neal@ctd.comsat.com (Neal Becker) To: dbeusee@us.oracle.com Cc: mcooper@usc.edu, neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: Which HPUX need -lPW In-Reply-To: <9402082104.AA07236@dbeusee.us.oracle.com> References: <9402082104.AA07236@dbeusee.us.oracle.com> >>>>> "Don" == Don Beusee writes: Don> I support rdist on hpux and I don't need -lPW. If this is true than it may depend on your flavor of yacc. If you use gnu bison, bison uses alloca. That explains it. So: If you use hpux and you use bison but you don't use gcc then you need -lPW. OK? From neal@ctd.comsat.com Tue Feb 8 13:24:37 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27081; Tue, 8 Feb 94 13:24:37 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pTzv8-0002fOC; Tue, 8 Feb 94 16:24 EST Message-Id: Date: Tue, 8 Feb 94 16:24 EST From: neal@ctd.comsat.com (Neal Becker) To: dbeusee@us.oracle.com Cc: mcooper@usc.edu, rdist-dev@usc.edu Subject: Re: Which HPUX need -lPW In-Reply-To: <9402082104.AA07236@dbeusee.us.oracle.com> References: <9402082104.AA07236@dbeusee.us.oracle.com> I use rdist on hpux 9.01 with gcc. I don't use -lPW. I have checked a little more. I can't find any reason for -lPW. From marc@synergy.Synergytics.Com Tue Feb 8 13:38:42 1994 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27723; Tue, 8 Feb 94 13:38:42 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id QAA29882; Tue, 8 Feb 1994 16:38:26 -0500 Message-Id: <199402082138.QAA29882@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 12:58:39 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 16:38:25 -0500 From: Marc Evans - Contract Software Hacker > Rdist works just like rsh. In fact, it uses rshd to connect to on the > remote host. If you run rdist on the local host as root, it runs as root on > the remote host. If you run rdist as a normal user, it runs as that user on > the remote host (provided .rhosts access is ok). The only reason the rdist > (client) programs needs to be setuid is to be able to bind to the (privelged) > rsh port on the remote host. Maybe we sould take this offline? Yes, I realize that it uses the rcmd(3) function to perform its work. I also get the feeling that you didn't look closely at the diffs based on your comment here. What my changes have done still uses rcmd(3) the same as you describe above. HOWEVER, by making the server SUID=root, and adding appropriate calls to play with the real/effective UID while the server is running, owners of files can be preserved during a push. Consider the following tree: grp1 contains user1, user2 grp2 contains user2 foo/ user1 grp1 755 foo/bar user2 grp1 444 foo/BAR user1 grp1 440 foo/FOO user2 grp1 440 foo/FOOBAR user2 grp2 440 Now let's walk through what happens with rdist BEFORE my changes: as user1 I try to push directory foo: - all files except foo/FOOBAR are pushed, and receive UID=user1. as user2 I try to push directory foo: - all files are pushed, and receive UID=user2 Compare that to what happens AFTER my changes are applied: as user1 I try to push directory foo: - all files except foo/FOOBAR are pushed, and preserve UID. as user2 I try to push directory foo: - all files are pushed, and preserve UID. Now then, it is clear that there is a security problem, in that user1 has created files with UID=user2, and vice-versa, when rdist has my patches applied. This of course makes system cringe when considering things like quotas (let alone other nifty tricks that could be used to sneak in a file under a different user' UID). However, for those of us sick enough to permit the above misuse potential, things like rcvs begin working much more pleasently, because owners, groups and modes of all files/directories are preserved in the local clone. Without these changes, rcvs *thinks* that all files with UID/GID mismatches are "out-of-date", resulting in some form of fixup (which over a dialup could be quite painful). I still don't understand how the calls to chown in the code I have seen ever worked without being SUID=root, but I do know that my changes worked well for our needs internally (though we are in the process of converting to sup as the transport layer for rcvs, replacing rdist), and I thought others may find it useful too (especially other rcvs users which are referred in the rcvs README file to use this flavor of rdist). - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From dbeusee@us.oracle.com Tue Feb 8 14:13:26 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29095; Tue, 8 Feb 94 14:13:26 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA03648; Tue, 8 Feb 1994 14:11:23 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08026; Tue, 8 Feb 94 14:09:34 PST Message-Id: <9402082209.AA08026@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 14:09:34 PST From: Don Beusee To: Marc@Synergytics.Com, mcooper@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 Cc: erickson@binky.ICS.UCI.EDU, rdist-dev@usc.EDU Chown should not be used when rdisting stuff as regular users. The files should be owned by the regular user on the other side regardless how they are owned on the local system. We don't want regular users to be able to push files and have them owned by root - that would be a security hole. From marc@synergy.Synergytics.Com Tue Feb 8 11:25:35 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA06094; Tue, 8 Feb 94 11:25:34 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id LAA20477; Tue, 8 Feb 1994 11:27:12 -0800 Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20065; Tue, 8 Feb 94 11:00:32 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id OAA29409; Tue, 8 Feb 1994 14:00:18 -0500 Message-Id: <199402081900.OAA29409@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 10:51:26 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 14:00:17 -0500 From: Marc Evans - Contract Software Hacker Status: R > > Hi - > > > > I have found that I needed the following changes to run on SVR4.0 (Dell i486) > > and SVR4.2 (NEC r4400). NOTE that I did NOT use #if's everyplace that I should > > have, so do not consider this a clean patch... > > > > It looks like you are trying to make rdist work correctly for normal > (non-root) users under SVR4. I've fixed this by other means in the > next release. Also, running rdistd setuid root is not advisible. > It was never intended to be setuid root and probably contains security > holes when run as such. Yes, you are correct in that I am trying to make rdist work correctly for non-root users under SVR4. You are also correct that there is great concern about security when havign to run SUID=root. I feel I must ask how you manage to get non-root users (of ANY OS, not just SVR4) to work properly without SUID=root? The key seems to be in the chown() function, which as I understand is only permitted to be called by the user root. In addition, the code is designed to consider the file out-of-date if the UID's don't match (unless the invoker explicitely overrides this test)... Can you possibly explain (without taking too much of your time) how you achieved your changes with respect to these observations? Thanks - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From dbeusee@us.oracle.com Tue Feb 8 14:23:58 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29710; Tue, 8 Feb 94 14:23:58 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA04545; Tue, 8 Feb 1994 14:23:49 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08267; Tue, 8 Feb 94 14:22:01 PST Message-Id: <9402082222.AA08267@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 14:22:01 PST From: Don Beusee To: neal@ctd.comsat.com Subject: Re: Which HPUX need -lPW Cc: mcooper@usc.edu, rdist-dev@usc.edu I'm using pure hpux. No gnu, no nothing. From neal@ctd.comsat.com Tue Feb 8 13:10:48 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07354; Tue, 8 Feb 94 13:10:48 PST Received: from neal.ctd.comsat.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA28843; Tue, 8 Feb 1994 13:12:28 -0800 Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pTzjG-0002fOC; Tue, 8 Feb 94 16:12 EST Message-Id: Date: Tue, 8 Feb 94 16:12 EST From: neal@ctd.comsat.com (Neal Becker) To: dbeusee@us Cc: mcooper@usc.edu, neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: Which HPUX need -lPW In-Reply-To: <9402082104.AA07236@dbeusee.us.oracle.com> References: <9402082104.AA07236@dbeusee.us.oracle.com> Status: R >>>>> "Don" == Don Beusee writes: Don> I support rdist on hpux and I don't need -lPW. If this is true than it may depend on your flavor of yacc. If you use gnu bison, bison uses alloca. That explains it. So: If you use hpux and you use bison but you don't use gcc then you need -lPW. OK? From dbeusee@us.oracle.com Tue Feb 8 14:27:26 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29990; Tue, 8 Feb 94 14:27:26 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA04721; Tue, 8 Feb 1994 14:27:24 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08287; Tue, 8 Feb 94 14:25:30 PST Message-Id: <9402082225.AA08287@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 14:25:30 PST From: Don Beusee To: Marc@Synergytics.Com, mcooper@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 Cc: erickson@binky.ICS.UCI.EDU, rdist-dev@usc.EDU I assume the client only runs as root during this step and then as the normal user the rest of the time, right? From mcooper@skat.usc.edu Tue Feb 8 13:23:13 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07484; Tue, 8 Feb 94 13:23:12 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA29702; Tue, 8 Feb 1994 13:24:55 -0800 Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25885; Tue, 8 Feb 94 12:58:44 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id MAA20729; Tue, 8 Feb 1994 12:58:40 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 12:58:39 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Marc@Synergytics.Com Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Tue, 08 Feb 1994 14:36:27 -0500 Message-Id: Status: R Rdist works just like rsh. In fact, it uses rshd to connect to on the remote host. If you run rdist on the local host as root, it runs as root on the remote host. If you run rdist as a normal user, it runs as that user on the remote host (provided .rhosts access is ok). The only reason the rdist (client) programs needs to be setuid is to be able to bind to the (privelged) rsh port on the remote host. mike From dbeusee@us.oracle.com Tue Feb 8 14:49:04 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01200; Tue, 8 Feb 94 14:49:04 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA06534; Tue, 8 Feb 1994 14:49:02 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08532; Tue, 8 Feb 94 14:47:14 PST Message-Id: <9402082247.AA08532@dbeusee.us.oracle.com> Date: Tue, 8 Feb 94 14:47:14 PST From: Don Beusee To: Marc@Synergytics.Com, mcooper@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 Cc: erickson@binky.ICS.UCI.EDU, rdist-dev@usc.EDU Please do not take this discussion offline and it affects all of us if this code should make it into the official rdist code. I think its a real bad idea to put any security hole into rdist that could be pursued by any regular user. If you have a site dependency, have rdist call a command after rdisting to fix the files ownership, or rdist as root. Actually one other alternative is to rdist to user1@dsthost in the distfile and put user1@srchost and user2@srchost in the .rhosts file for user1 on dsthost. Regards, Don. From marc@synergy.Synergytics.Com Tue Feb 8 14:05:30 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA07938; Tue, 8 Feb 94 14:05:29 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id OAA03182; Tue, 8 Feb 1994 14:07:07 -0800 Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27723; Tue, 8 Feb 94 13:38:42 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id QAA29882; Tue, 8 Feb 1994 16:38:26 -0500 Message-Id: <199402082138.QAA29882@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 12:58:39 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 16:38:25 -0500 From: Marc Evans - Contract Software Hacker Status: R > Rdist works just like rsh. In fact, it uses rshd to connect to on the > remote host. If you run rdist on the local host as root, it runs as root on > the remote host. If you run rdist as a normal user, it runs as that user on > the remote host (provided .rhosts access is ok). The only reason the rdist > (client) programs needs to be setuid is to be able to bind to the (privelged) > rsh port on the remote host. Maybe we sould take this offline? Yes, I realize that it uses the rcmd(3) function to perform its work. I also get the feeling that you didn't look closely at the diffs based on your comment here. What my changes have done still uses rcmd(3) the same as you describe above. HOWEVER, by making the server SUID=root, and adding appropriate calls to play with the real/effective UID while the server is running, owners of files can be preserved during a push. Consider the following tree: grp1 contains user1, user2 grp2 contains user2 foo/ user1 grp1 755 foo/bar user2 grp1 444 foo/BAR user1 grp1 440 foo/FOO user2 grp1 440 foo/FOOBAR user2 grp2 440 Now let's walk through what happens with rdist BEFORE my changes: as user1 I try to push directory foo: - all files except foo/FOOBAR are pushed, and receive UID=user1. as user2 I try to push directory foo: - all files are pushed, and receive UID=user2 Compare that to what happens AFTER my changes are applied: as user1 I try to push directory foo: - all files except foo/FOOBAR are pushed, and preserve UID. as user2 I try to push directory foo: - all files are pushed, and preserve UID. Now then, it is clear that there is a security problem, in that user1 has created files with UID=user2, and vice-versa, when rdist has my patches applied. This of course makes system cringe when considering things like quotas (let alone other nifty tricks that could be used to sneak in a file under a different user' UID). However, for those of us sick enough to permit the above misuse potential, things like rcvs begin working much more pleasently, because owners, groups and modes of all files/directories are preserved in the local clone. Without these changes, rcvs *thinks* that all files with UID/GID mismatches are "out-of-date", resulting in some form of fixup (which over a dialup could be quite painful). I still don't understand how the calls to chown in the code I have seen ever worked without being SUID=root, but I do know that my changes worked well for our needs internally (though we are in the process of converting to sup as the transport layer for rcvs, replacing rdist), and I thought others may find it useful too (especially other rcvs users which are referred in the rcvs README file to use this flavor of rdist). - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From stssram@st.unocal.com Tue Feb 8 15:00:12 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01616; Tue, 8 Feb 94 15:00:12 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id PAA17331; Tue, 8 Feb 1994 15:00:09 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA02987; Tue, 8 Feb 94 15:00:07 PST Message-Id: <9402082300.AA02987@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Tue, 8 Feb 1994 15:00:06 -0800 In-Reply-To: Marc Evans - Contract Software Hacker "Re: problem with rdist under SunOS 5.2" (Feb 8, 16:38) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Marc@Synergytics.Com Subject: Re: problem with rdist under SunOS 5.2 Cc: Scott Erickson , rdist-dev@usc.EDU, "Michael A. Cooper" On Feb 8, 16:38, Marc Evans - Contract Software Hacker wrote: } Subject: Re: problem with rdist under SunOS 5.2 > > Now then, it is clear that there is a security problem, in that user1 has > created files with UID=user2, and vice-versa, when rdist has my patches > applied. This of course makes system cringe when considering things like quotas > (let alone other nifty tricks that could be used to sneak in a file under a > different user' UID). However, for those of us sick enough to permit the above This is precisely why I think rdist works correctly as is, before your changes. You *should* need root privilege to create files owned by someone else. If you need to create files owned by someone else on a remote system for some special application, I think you need to start thinking about very limited setuid root programs that start up the rdists you need. It should not be part of rdist itself; the security problem is *far* too large. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From mcooper@ucs.usc.edu Tue Feb 8 15:02:15 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01688; Tue, 8 Feb 94 15:02:15 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id PAA22041; Tue, 8 Feb 1994 15:02:12 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 15:02:11 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Don Beusee Cc: Marc@Synergytics.Com, erickson@binky.ICS.UCI.EDU, rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Tue, 8 Feb 94 14:25:30 PST Message-Id: > I assume the client only runs as root during this step and then as the normal > user the rest of the time, right? > > >From mcooper@skat.usc.edu Tue Feb 8 13:23:13 1994 > Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) > id AA07484; Tue, 8 Feb 94 13:23:12 PST > Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) > id NAA29702; Tue, 8 Feb 1994 13:24:55 -0800 > Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) > id AA25885; Tue, 8 Feb 94 12:58:44 PST > Received: from localhost (mcooper@localhost) > by acamar.usc.edu (8.6.4/8.6.4) > id MAA20729; Tue, 8 Feb 1994 12:58:40 -0800 > Sender: "Michael A. Cooper" > Date: Tue, 8 Feb 94 12:58:39 PST > From: "Michael A. Cooper" > Reply-To: mcooper@usc.EDU > To: Marc@Synergytics.Com > Cc: Scott Erickson , rdist-dev@usc.EDU > Subject: Re: problem with rdist under SunOS 5.2 > In-Reply-To: Your message of Tue, 08 Feb 1994 14:36:27 -0500 > Message-Id: > Status: R > > Rdist works just like rsh. In fact, it uses rshd to connect to on the > remote host. If you run rdist on the local host as root, it runs as root on > the remote host. If you run rdist as a normal user, it runs as that user on > the remote host (provided .rhosts access is ok). The only reason the rdist > (client) programs needs to be setuid is to be able to bind to the (privelged) > rsh port on the remote host. > > mike > > Yes, only during the rcmd() call does it run as root. mike From marc@synergy.Synergytics.Com Tue Feb 8 15:09:02 1994 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02028; Tue, 8 Feb 94 15:09:02 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id SAA00489; Tue, 8 Feb 1994 18:08:22 -0500 Message-Id: <199402082308.SAA00489@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: stssram@st.unocal.com (Bob Myers) Cc: Scott Erickson , rdist-dev@usc.EDU, "Michael A. Cooper" Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 15:00:06 PST." <9402082300.AA02987@st.unocal.com> X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 18:08:22 -0500 From: Marc Evans - Contract Software Hacker Yes, I agree with the numerous folks that have replied to me about not wishing to have the massive security whole added to rdist. I do think that some attension should be applied to the issue of the out-dating technique, which is probably the real base of the problme my patch addressed (which resolved rcvs use problems). I would suggest that simply having a UID/USERNAME mismatch from client to server is not sufficinet grounds for considering the file out-dated, but rather a flag to look closer, possibly by running sum again both copies to determine if the contents are the same... - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From mcooper@ucs.usc.edu Tue Feb 8 16:59:58 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06821; Tue, 8 Feb 94 16:59:58 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id QAA23135; Tue, 8 Feb 1994 16:59:20 -0800 Sender: "Michael A. Cooper" Date: Tue, 8 Feb 94 16:59:20 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.EDU To: Marc@Synergytics.Com Cc: stssram@st.unocal.com (Bob Myers), Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of Tue, 08 Feb 1994 18:08:22 -0500 Message-Id: I plan on modifying rdist such that it will consider a uid/gid mismatch as an out of date condition only if it's running as root (since root can chown/chgrp). If rdist is running as a normal user, rdist will not do a uid/gid check. I will add an option that allows you to explicitly disable and enable the uid/gid check no matter if you are root or a normal user. mike From marc@synergy.Synergytics.Com Tue Feb 8 18:59:04 1994 Return-Path: Received: from synergy.Synergytics.Com ([192.80.84.133]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10706; Tue, 8 Feb 94 18:59:04 PST Received: from synergy.Synergytics.Com (localhost [127.0.0.1]) by Synergytics.Com (8.6.5/8.6.5) with ESMTP id VAA01064; Tue, 8 Feb 1994 21:58:49 -0500 Message-Id: <199402090258.VAA01064@Synergytics.Com> Organization: Synergytics, (603) 635-3857 Reply-To: Marc@Synergytics.Com To: mcooper@usc.EDU Cc: stssram@st.unocal.com (Bob Myers), Scott Erickson , rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: Your message of "Tue, 08 Feb 1994 16:59:20 PST." X-Mailer: exmh version 1.2 1/14/94 Date: Tue, 08 Feb 1994 21:58:48 -0500 From: Marc Evans - Contract Software Hacker > I plan on modifying rdist such that it will consider a uid/gid mismatch as an > out of date condition only if it's running as root (since root can > chown/chgrp). If rdist is running as a normal user, rdist will not > do a uid/gid check. I will add an option that allows you to explicitly > disable and enable the uid/gid check no matter if you are root or a normal > user. That sounds like a reasonable resolution 8-) - Marc /| -----------------------. ~ . ~ X|=| Marc N. Evans |------------------. ~ . X| | Software Consultant | Synergytics |-------------------------------. X| | Marc@Synergytics.Com | 21 Hinds Lane | Specializing in: | X| | (603) 635-3857 | Pelham, NH, USA | - Unix internals/applications | X|=|______________________| 03076-3013 | - X11 internals/applications | X| (____________________| | X| (_________________________________| X| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From anthony.datri@amd.com Wed Feb 9 07:50:37 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27370; Wed, 9 Feb 94 07:50:37 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA14648 (5.67a/IDA-1.5+AMD for ); Wed, 9 Feb 1994 07:50:34 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA01754 (5.67a/IDA-1.5+AMD for ); Wed, 9 Feb 1994 07:50:33 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA24965; Wed, 9 Feb 94 09:50:31 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA09618; Wed, 9 Feb 94 09:50:40 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Wed, 9 Feb 1994 09:50:39 -0600 (CST) Message-Id: Date: Wed, 9 Feb 1994 09:50:39 -0600 (CST) From: "Anthony A. Datri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.EDU Subject: Re: problem with rdist under SunOS 5.2 In-Reply-To: References: > I will add an option that allows you to explicitly >disable and enable the uid/gid check no matter if you are root or a normal >user. Thank you. Right now I have some grief from HP's that insist on having bizarre uid mappings. ======================================================================8--< From t016479@voodoo.ch.swissbank.com Thu Feb 10 06:40:59 1994 Return-Path: Received: from swissbank.swissbank.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16903; Thu, 10 Feb 94 06:40:59 PST Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.9) id AA08312; Thu, 10 Feb 94 08:41:44 CST Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.8) id AA21080; Thu, 10 Feb 94 08:40:16 CST Received: from chmail.ch.swissbank.com (chmailhost) by il.us.swissbank.com (4.1/SMI-4.1) id AA19173; Thu, 10 Feb 94 08:42:05 CST Received: from ge.ch.swissbank.com (chgvau01) by chmail.ch.swissbank.com with SMTP id AA23333 (5.67a/IDA-1.5 for ); Thu, 10 Feb 1994 15:40:27 +0100 Received: from voodoo. by ge.ch.swissbank.com (4.1/SMI-4.1/grizzly_240993) id AA19569; Thu, 10 Feb 94 15:38:54 +0100 Received: by voodoo. (4.1/SMI-4.1) id AA13939; Thu, 10 Feb 94 15:38:53 +0100 Date: Thu, 10 Feb 94 15:38:53 +0100 From: t016479@voodoo.ch.swissbank.com (Sean Boran) Message-Id: <9402101438.AA13939@voodoo.> To: rdist-dev@usc.edu Subject: Rdist: FAQ / Future Cc: sean@ge.ch.swissbank.com Hello, I'm new to this list. Is there a FAQ? What work is being done on rdist at the moment? I have V6.0. I was wondering whether there are plans to . get rid of the need for /.rhost files? . add some kind of authentification file, restricting access to clients? . support special files - sockets (possible?) . enhance the syntax of distfile? For instance making it easier to compare/update directories which don't have the same name or path? . use TLI ? . extend rdist to compare SVR4 packages? I'll email a SUMMARY of replies to anyone who asks me. Thanks in advance, Sean |Sean Boran Tel (switz.): 022-376.44.28 | |Swiss Bank Corporation Email: Boran.Sean@ch.swissbank.com | |Geneva, Switzerland ^^^^^^^^^^ new,official addr.| |_________________________________________________________________| From stssram@st.unocal.com Thu Feb 10 07:58:10 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18788; Thu, 10 Feb 94 07:58:10 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id HAA01610; Thu, 10 Feb 1994 07:57:44 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA01234; Thu, 10 Feb 94 07:57:25 PST Message-Id: <9402101557.AA01234@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Thu, 10 Feb 1994 07:57:25 -0800 In-Reply-To: t016479@voodoo.ch.swissbank.com (Sean Boran) "Rdist: FAQ / Future" (Feb 10, 15:38) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu, Boran.Sean@ch.swissbank.com Subject: Re: Rdist: FAQ / Future On Feb 10, 15:38, Sean Boran wrote: } Subject: Rdist: FAQ / Future > > I was wondering whether there are plans to > > . get rid of the need for /.rhost files? > . add some kind of authentification file, restricting > access to clients? I'd just like to point out that the .rhost file IS the authentication file. Why do you want to get rid of it, and add some *other* authentication file? If you have full rdist capability, there's nothing you can't do on the remote machine anyway, particularly through "special" commands. This seems an odd pair of requests to me. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From mcooper@ucs.usc.edu Thu Feb 10 17:01:36 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10857; Thu, 10 Feb 94 17:01:36 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id QAA13663; Thu, 10 Feb 1994 16:59:55 -0800 Sender: "Michael A. Cooper" Date: Thu, 10 Feb 94 16:59:54 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: t016479@voodoo.ch.swissbank.com (Sean Boran) Cc: rdist-dev@usc.edu, sean@ge.ch.swissbank.com Subject: Re: Rdist: FAQ / Future In-Reply-To: Your message of Thu, 10 Feb 94 15:38:53 +0100 Message-Id: There is no rdist FAQ as far as I know. As of 2 days ago I am working on a new bug-fix release of rdist to be called 6.1beta.3. I _hope_ to release it in a few weeks, but don't hold your breath. Whenever I say something like that, some major emergency or series there of occurs. Version 6.1beta.2 is the last version out. Version 6.0 is probably more stable. There are no plans to get rid of .rhosts or the whole rsh scheme. I'll think about adding special file support. I'm not sure how easy that will be. I'm not sure how you want make things easier to compare/update directories with different pathnames. I have no plans to add SVR4 pkg support to rdist. I'm not sure why or how you would do such a thing. mike From hohmuth@irs.inf.tu-dresden.de Mon Feb 14 19:44:28 1994 Return-Path: Received: from irzr17.inf.tu-dresden.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17735; Mon, 14 Feb 94 19:44:28 PST Received: by irzr17.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA05551; Tue, 15 Feb 1994 04:41:31 +0100 From: hohmuth@irs.inf.tu-dresden.de (Michael Hohmuth) Message-Id: <9402150341.AA05551@irzr17.inf.tu-dresden.de> Subject: Protecting root accounts of hosts being rdisted To: rdist-dev@usc.edu Date: Tue, 15 Feb 1994 04:41:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5694 I just thought the following [after my .sig] might be useful as long as `rdist' is lacking a pull feature. Here's an excerpt from the README: `rdc' is a wrapper around the `rdist' server (which is called `rdistd' in newer versions of `rdist'). It tries to make the host running the server (the host being updated) more secure by making it unnecessary to open the "root" account to the host that enforces the update. That way, files can still be updated, but `rsh' access is prevented. Michael -- Internet: hohmuth@irs.inf.tu-dresden.de Submitted-by: hohmuth@irs.inf.tu-dresden.de Archive-name: rdc-0.9/part01 ---- Cut Here and feed the following to sh ---- #!/bin/sh # This is rdc-0.9, a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 02/15/1994 03:37 UTC by hohmuth@irs.inf.tu-dresden.de # Source directory /usr/users/lfk/hohmuth/src # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 2357 -rw-r--r-- rdc-0.9/README # 1025 -rw-r--r-- rdc-0.9/rdc.c # # ============= rdc-0.9/README ============== if test ! -d 'rdc-0.9'; then echo 'x - creating directory rdc-0.9' mkdir 'rdc-0.9' fi if test -f 'rdc-0.9/README' -a X"$1" != X"-c"; then echo 'x - skipping rdc-0.9/README (File already exists)' else echo 'x - extracting rdc-0.9/README (Text)' sed 's/^X//' << 'SHAR_EOF' > 'rdc-0.9/README' && /* `rdc' - a wrapper around `rdistd' (resp. `rdist') X X written by Michael Hohmuth X and placed in the public domain X X NO WARRANTY! */ X X WHAT IT DOES X `rdc' is a wrapper around the `rdist' server (which is called `rdistd' in newer versions of `rdist'). It tries to make the host running the server (the host being updated) more secure by making it unnecessary to open the "root" account to the host that enforces the update. That way, files can still be updated, but `rsh' access is prevented. X X HOW IT WORKS X This is accomplished by creating a special account (for instance, "rdc") on the machine running `rdistd' with root privileges and `rdc' as its login shell. The `rdc' account would be opened for "rsh" access from the file server (via an entry in ~rdc/.rhosts), and the file server would use "rdc@host" instead of "host" as the destination. X `rdc' can only work if an explicit path name for `rdistd' is compiled into the file server's `rdist' (i.e., if the file server does not assume PATH searches on destination hosts). It just checks if the command requested from the file server host would really run `rdistd', and if so, the command is executed. X X INSTALLATION X o Create an account for `rdc'. An example line in /etc/passwd might look X like: X X rdc:Nologin:0:1:Remote Distribution Service Account:/usr/users/system/rdc:/usr/users/system/rdc/rdc X o Edit rdc.c. You need to specify what version of `rdist' you use and X where the `rdist' server resides. X X Note: The code assumes you have an ASCI C compliant C compiler (like X `gcc'). If you don't, you need to edit the line containing "strcmp" X (it uses ANSI-C-like string concatanation). X o Compile the `rdc' program. Exapmle: X X gcc -O -s -o rdc rdc.c X o Install the program. Example: X X cp rdc /usr/users/system/rdc/rdc X o Create entries in ~rdc/.rhosts for file servers (just as you would X normally do with /.rhosts). X X Don't forget to remove those entrys from /.rhosts. X o Tell the file server host's administration to use the rdc account X instead of the root account as their destination (e.g., "rdc@host" X instead of just "host"). X X NO COPYRIGHT AND NO WARRANTY X This program is in the public domain. There is no warranty whatsoever. X -- Michael Hohmuth SHAR_EOF chmod 0644 rdc-0.9/README || echo 'restore of rdc-0.9/README failed' Wc_c="`wc -c < 'rdc-0.9/README'`" test 2357 -eq "$Wc_c" || echo 'rdc-0.9/README: original size 2357, current size' "$Wc_c" fi # ============= rdc-0.9/rdc.c ============== if test -f 'rdc-0.9/rdc.c' -a X"$1" != X"-c"; then echo 'x - skipping rdc-0.9/rdc.c (File already exists)' else echo 'x - extracting rdc-0.9/rdc.c (Text)' sed 's/^X//' << 'SHAR_EOF' > 'rdc-0.9/rdc.c' && /* `rdc' - a wrapper around `rdistd' (resp. `rdist') X X written by Michael Hohmuth X and placed in the public domain X X NO WARRANTY! */ X #include #include #include X /* CONFIGURATION SECTION */ X /* define RDIST6 if you have `rdist' version 6.0 or greater */ /* #define RDIST6 */ X /* define RDISTD_PATH to the path of the rdist server (for version 6, this X is the path to `rdistd'; for older versions, this is the path to `rdist' */ #define RDISTD_PATH "/usr/local/rdist/rdist" X /* END OF CONFIGURATION SECTION */ X #ifdef RDIST6 #define RDISTD_FLAG "-S" #else #define RDISTD_FLAG "-Server" #endif X #define FATAL(errmsg) { fputs(errmsg, stderr); exit(1); } X int main(argc, argv) X int argc; X char **argv; { X X if ((argc != 3) || X strcmp(argv[1], "-c") || X strcmp(argv[2], RDISTD_PATH " " RDISTD_FLAG)) /* needs ANSI C */ X { X FATAL("Access denied.\n"); X } X X execl(RDISTD_PATH, RDISTD_PATH, RDISTD_FLAG, NULL); X X /*NOTREACHED*/ X return 0; } SHAR_EOF chmod 0644 rdc-0.9/rdc.c || echo 'restore of rdc-0.9/rdc.c failed' Wc_c="`wc -c < 'rdc-0.9/rdc.c'`" test 1025 -eq "$Wc_c" || echo 'rdc-0.9/rdc.c: original size 1025, current size' "$Wc_c" fi exit 0 From stssram@st.unocal.com Mon Feb 14 21:15:44 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20359; Mon, 14 Feb 94 21:15:44 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id VAA01828; Mon, 14 Feb 1994 21:15:42 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA22215; Mon, 14 Feb 94 21:15:40 PST Message-Id: <9402150515.AA22215@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Mon, 14 Feb 1994 21:15:39 -0800 In-Reply-To: hohmuth@irzr17.inf.tu-dresden.de (Michael Hohmuth) "Protecting root accounts of hosts being rdisted" (Feb 15, 4:41) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hohmuth@irzr17.inf.tu-dresden.de (Michael Hohmuth), rdist-dev@usc.edu Subject: Re: Protecting root accounts of hosts being rdisted On Feb 15, 4:41, Michael Hohmuth wrote: } Subject: Protecting root accounts of hosts being rdisted > I just thought the following [after my .sig] might be useful as long as > `rdist' is lacking a pull feature. Here's an excerpt from the README: > > `rdc' is a wrapper around the `rdist' server (which is called `rdistd' > in newer versions of `rdist'). It tries to make the host running the > server (the host being updated) more secure by making it unnecessary to > open the "root" account to the host that enforces the update. That > way, files can still be updated, but `rsh' access is prevented. This is cute, but.... What you're really depending on here is security through obscurity, and very minimal obscurity, at that. Anyone familiar with rdist should quickly be able to see what's wrong.... A few examples: 1) rdist a new passwd file to the target machine, get in and do whatever you like. 2) Just rdist any file you want to, replacing any file on the remote system easily. 3) Use a "special" command to execute any command you like on the remote machine. Your "rdc" does not protect against any of the above attacks. The only thing that fails is rsh, and rdist to @host instead of rdc@host. The only way this "security" feature works is if no one knows about "rdc". If whoever you're trying to protect against ever finds out about rdc, you're toast. The only way to really make this work is to have some sort of permission list built into rdistd. You'd have to have a file somewhere on each client machine that indicated what rdist from each server was allowed to do to that machine, particularly in the way of "special" shell commands, but also including system files like the passwd file and the rdist permission file itself. Frankly, I think it's easier to use a pull system. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From mh1@irz.inf.tu-dresden.de Mon Feb 14 21:54:18 1994 Return-Path: Received: from irz301.inf.tu-dresden.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21306; Mon, 14 Feb 94 21:54:18 PST Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA02830; Tue, 15 Feb 1994 06:48:46 +0100 From: mh1@irz.inf.tu-dresden.de (Michael Hohmuth) Message-Id: <9402150548.AA02830@irz301.inf.tu-dresden.de> Subject: Re: Protecting root accounts of hosts being rdisted To: stssram@st.unocal.com (Bob Myers) Date: Tue, 15 Feb 1994 06:48:45 +0100 (MET) Cc: rdist-dev@usc.edu In-Reply-To: <9402150515.AA22215@st.unocal.com> from "Bob Myers" at Feb 14, 94 09:15:39 pm Reply-To: hohmuth@irzr17.inf.tu-dresden.de X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 706 Bob Myers: > Your "rdc" does not protect against any of the above attacks. The only > thing that fails is rsh, and rdist to @host instead of rdc@host. The only > way this "security" feature works is if no one knows about "rdc". > > If whoever you're trying to protect against ever finds out about rdc, you're > toast. Hmm.. Thanks for making that clear. I failed to do so in my post. For me, this program is still useful. This is because I trust root on the rdisting host (i.e., I know they won't try to attack my system), partly because I have control over that host, too, but I don't want them to accidently execute commands on my system. Michael -- Internet: hohmuth@freia.inf.tu-dresden.de From dbeusee@us.oracle.com Mon Feb 14 22:43:47 1994 Return-Path: Received: from keymaster.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22450; Mon, 14 Feb 94 22:43:47 PST Received: from dbeusee.us.oracle.com by keymaster.us.oracle.com with SMTP (8.6.4/37.7) id WAA20696; Mon, 14 Feb 1994 22:43:30 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09730; Mon, 14 Feb 94 22:40:14 PST Message-Id: <9402150640.AA09730@dbeusee.us.oracle.com> Date: Mon, 14 Feb 94 22:40:14 PST From: Don Beusee To: hohmuth@irzr17.inf.tu-dresden.de, rdist-dev@usc.edu, stssram@st.unocal.com Subject: Re: Protecting root accounts of hosts being rdisted Bob is correct. Use the following distfile to go in without even messing with any files: /tmp/dummyfile -> interestinghost install; cmdspecial "rm -f /tmp/dummyfile; any command here"; From stssram@st.unocal.com Mon Feb 14 21:34:57 1994 Received: from keymaster.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA08997; Mon, 14 Feb 94 21:34:24 PST Received: from usc.edu by keymaster.us.oracle.com with SMTP (8.6.4/37.7) id VAA19014; Mon, 14 Feb 1994 21:36:01 -0800 Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20359; Mon, 14 Feb 94 21:15:44 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id VAA01828; Mon, 14 Feb 1994 21:15:42 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA22215; Mon, 14 Feb 94 21:15:40 PST Message-Id: <9402150515.AA22215@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Mon, 14 Feb 1994 21:15:39 -0800 In-Reply-To: hohmuth@irzr17.inf.tu-dresden.de (Michael Hohmuth) "Protecting root accounts of hosts being rdisted" (Feb 15, 4:41) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hohmuth@irzr17.inf.tu-dresden.de (Michael Hohmuth), rdist-dev@usc.edu Subject: Re: Protecting root accounts of hosts being rdisted Status: R On Feb 15, 4:41, Michael Hohmuth wrote: } Subject: Protecting root accounts of hosts being rdisted > I just thought the following [after my .sig] might be useful as long as > `rdist' is lacking a pull feature. Here's an excerpt from the README: > > `rdc' is a wrapper around the `rdist' server (which is called `rdistd' > in newer versions of `rdist'). It tries to make the host running the > server (the host being updated) more secure by making it unnecessary to > open the "root" account to the host that enforces the update. That > way, files can still be updated, but `rsh' access is prevented. This is cute, but.... What you're really depending on here is security through obscurity, and very minimal obscurity, at that. Anyone familiar with rdist should quickly be able to see what's wrong.... A few examples: 1) rdist a new passwd file to the target machine, get in and do whatever you like. 2) Just rdist any file you want to, replacing any file on the remote system easily. 3) Use a "special" command to execute any command you like on the remote machine. Your "rdc" does not protect against any of the above attacks. The only thing that fails is rsh, and rdist to @host instead of rdc@host. The only way this "security" feature works is if no one knows about "rdc". If whoever you're trying to protect against ever finds out about rdc, you're toast. The only way to really make this work is to have some sort of permission list built into rdistd. You'd have to have a file somewhere on each client machine that indicated what rdist from each server was allowed to do to that machine, particularly in the way of "special" shell commands, but also including system files like the passwd file and the rdist permission file itself. Frankly, I think it's easier to use a pull system. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From dbeusee@us.oracle.com Mon Feb 14 23:02:50 1994 Return-Path: Received: from keymaster.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22833; Mon, 14 Feb 94 23:02:50 PST Received: from dbeusee.us.oracle.com by keymaster.us.oracle.com with SMTP (8.6.4/37.7) id XAA21060; Mon, 14 Feb 1994 23:02:24 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09845; Mon, 14 Feb 94 22:59:09 PST Message-Id: <9402150659.AA09845@dbeusee.us.oracle.com> Date: Mon, 14 Feb 94 22:59:09 PST From: Don Beusee To: hohmuth@irzr17.inf.tu-dresden.de, stssram@st.unocal.com Subject: Re: Protecting root accounts of hosts being rdisted Cc: rdist-dev@usc.edu You have not made it all that harder for them to "accidentially" execute commands as root on your machine. Instead of: rsh YOURHOST 'COMMAND' They just do: cat < /tmp/dummyfile /tmp/dummyfile -> YOURHOST special "rm -f /tmp/dummyfile; COMMAND"; EOF touch /tmp/dummyfile; rdist -f /tmp/distfile; rm -f /tmp/distfile Regards, Don. From mh1@irz301.inf.tu-dresden.de Mon Feb 14 22:12:56 1994 Received: from keymaster.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA09444; Mon, 14 Feb 94 22:12:06 PST Received: from usc.edu by keymaster.us.oracle.com with SMTP (8.6.4/37.7) id WAA20063; Mon, 14 Feb 1994 22:13:26 -0800 Received: from irz301.inf.tu-dresden.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21306; Mon, 14 Feb 94 21:54:18 PST Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA02830; Tue, 15 Feb 1994 06:48:46 +0100 From: mh1@irz301.inf.tu-dresden.de (Michael Hohmuth) Message-Id: <9402150548.AA02830@irz301.inf.tu-dresden.de> Subject: Re: Protecting root accounts of hosts being rdisted To: stssram@st.unocal.com (Bob Myers) Date: Tue, 15 Feb 1994 06:48:45 +0100 (MET) Cc: rdist-dev@usc.edu In-Reply-To: <9402150515.AA22215@st.unocal.com> from "Bob Myers" at Feb 14, 94 09:15:39 pm Reply-To: hohmuth@irzr17.inf.tu-dresden.de X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 706 Status: R Bob Myers: > Your "rdc" does not protect against any of the above attacks. The only > thing that fails is rsh, and rdist to @host instead of rdc@host. The only > way this "security" feature works is if no one knows about "rdc". > > If whoever you're trying to protect against ever finds out about rdc, you're > toast. Hmm.. Thanks for making that clear. I failed to do so in my post. For me, this program is still useful. This is because I trust root on the rdisting host (i.e., I know they won't try to attack my system), partly because I have control over that host, too, but I don't want them to accidently execute commands on my system. Michael -- Internet: hohmuth@freia.inf.tu-dresden.de From stssram@st.unocal.com Mon Feb 14 23:26:42 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23251; Mon, 14 Feb 94 23:26:42 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id XAA08344; Mon, 14 Feb 1994 23:26:41 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA23041; Mon, 14 Feb 94 23:26:40 PST Message-Id: <9402150726.AA23041@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Mon, 14 Feb 1994 23:26:39 -0800 In-Reply-To: mh1@irz301.inf.tu-dresden.de (Michael Hohmuth) "Re: Protecting root accounts of hosts being rdisted" (Feb 15, 6:48) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hohmuth@irzr17.inf.tu-dresden.de Subject: Re: Protecting root accounts of hosts being rdisted Cc: rdist-dev@usc.edu On Feb 15, 6:48, Michael Hohmuth wrote: } Subject: Re: Protecting root accounts of hosts being rdisted > Bob Myers: > > > If whoever you're trying to protect against ever finds out about rdc, you're > > toast. > > For me, this program is still useful. This is because I trust root on > the rdisting host (i.e., I know they won't try to attack my system), partly > because I have control over that host, too, but I don't want them to > accidently execute commands on my system. Might I suggest that future distributions of rdc explicitly note that this is not really a security feature, but more of an accident prevention feature? I wouldn't want any naive sysadmins out there to get the wrong idea. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From t016479@voodoo.ch.swissbank.com Tue Feb 15 00:22:37 1994 Return-Path: Received: from swissbank.swissbank.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24501; Tue, 15 Feb 94 00:22:37 PST Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.9) id AA28098; Tue, 15 Feb 94 02:23:16 CST Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.8) id AA14977; Tue, 15 Feb 94 02:21:56 CST Received: from chmail.ch.swissbank.com (chmailhost) by il.us.swissbank.com (4.1/SMI-4.1) id AA18478; Tue, 15 Feb 94 02:23:51 CST Received: from ge.ch.swissbank.com (chgvau01) by chmail.ch.swissbank.com with SMTP id AA29205 (5.67a/IDA-1.5); Tue, 15 Feb 1994 09:22:10 +0100 Received: from voodoo. by ge.ch.swissbank.com (4.1/SMI-4.1/grizzly_240993) id AA12302; Tue, 15 Feb 94 09:20:31 +0100 Received: by voodoo. (4.1/SMI-4.1) id AA20686; Tue, 15 Feb 94 09:20:30 +0100 Date: Tue, 15 Feb 94 09:20:30 +0100 From: t016479@voodoo.ch.swissbank.com (Sean Boran) Message-Id: <9402150820.AA20686@voodoo.> To: rdist-dev@usc.edu Subject: Summary: Rdist: FAQ / Future Cc: sean@ge.ch.swissbank.com, dswalins@us.oracle.com Well, this is a summary of responses received. I have cut out non essential text. Given what you can do with rdist, removing .rhosts doesn't help security. I think that if rdistd used an "access list" file to decide whether to accept a connection, it would improve security. (Something like "hosts.allow" used by the tcpd inetd wrappers). Regards, Sean > On Feb 10, 15:38, Original Question: > > I'm new to this list. Is there a FAQ? What work is > being done on rdist at the moment? I have V6.0. > > I was wondering whether there are plans to > > . get rid of the need for /.rhost files? > . add some kind of authentification file, restricting > access to clients? > . support special files - sockets (possible?) > . enhance the syntax of distfile? For instance making it > easier to compare/update directories which don't have > the same name or path? > . use TLI ? > . extend rdist to compare SVR4 packages? 1> From: stssram@st.unocal.com (Bob Myers) 1> Date: Thu, 10 Feb 1994 07:57:25 -0800 1> Organization: Unocal Exploration and Seismic Technology 1> 1> I'd just like to point out that the .rhost file IS the authentication file. 1> Why do you want to get rid of it, and add some *other* authentication file? 1> If you have full rdist capability, there's nothing you can't do on the 1> remote machine anyway, particularly through "special" commands. 1> 1> This seems an odd pair of requests to me. 1> 1> The only way to make rdist work while restricting rcp/rsh type activities 1> would be with another security file that restricts what sorts of things 1> different servers can do with an rdist to that client. This would require a 1> very detailed control file on the client. If that's what you want, I'd 1> suggest using one of the "pull" type software distribution programs (like 1> "track") instead of a "push" system. That way, you don't have to worry 1> about machines being infiltrated from a central server. 2> Sender: "Michael A. Cooper" 2> Date: Thu, 10 Feb 94 16:59:54 PST 2> 2> There is no rdist FAQ as far as I know. 2> As of 2 days ago I am working on a new bug-fix release of rdist to 2> be called 6.1beta.3. I _hope_ to release it in a few weeks, but 2> don't hold your breath. Whenever I say something like that, some 2> major emergency or series there of occurs. 2> 2> Version 6.1beta.2 is the last version out. Version 6.0 is probably more 2> stable. 2> There are no plans to get rid of .rhosts or the whole rsh scheme. 2> 2> I'll think about adding special file support. I'm not sure how easy 2> that will be. 2> 2> I'm not sure how you want make things easier to compare/update directories 2> with different pathnames. 2> 2> I have no plans to add SVR4 pkg support to rdist. I'm not sure why or 2> how you would do such a thing. 3> Date: Fri, 11 Feb 94 08:52:54 +0100 3> From: t016479 (Sean Boran) 3> 3> Well, it is better to compare pkgs than files, because a pkg normally 3> has cleanup/startup scripts included, so if a pkg is out of date 3> it is better to do a pkgrm & pkgadd that to update the files. 3> If the files are updated directly, the the package database will also 3> get out of sync. 3> 3> I realise that package synchronisation is a completely different problem to 3> file synchronisation. In fact patches also need to be synchronised too. 3> However "pkginfo" doesn't tell you what the patchlevel of a certain package 3> is, "installpatch -p" will give a list of patches installed, but mother 3> package info. Perhaps I could hack installpatch a bit. 3> 3> Thanks very much for the answers. I'll try & think a bit about pkgs, 3> perhaps I can make an (intelligent??) suggestion. |Sean Boran Tel (switz.): 022-376.44.28 | |Swiss Bank Corporation Email: Boran.Sean@ch.swissbank.com | |Geneva, Switzerland ^^^^^^^^^^ new,official addr.| |_________________________________________________________________| From CTRIBBET@INDYVAX.IUPUI.EDU Wed Feb 16 08:40:10 1994 Return-Path: Received: from indyvax.iupui.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26053; Wed, 16 Feb 94 08:40:10 PST Received: from INDYVAX.IUPUI.EDU by INDYVAX.IUPUI.EDU (PMDF V4.2-12 #5862) id <01H8YA7VLOSG0069UE@INDYVAX.IUPUI.EDU>; Wed, 16 Feb 1994 11:39:59 -0500 Date: Wed, 16 Feb 1994 11:39:59 -0500 From: CTRIBBET@INDYVAX.IUPUI.EDU Subject: Solaris2.3 and rdist To: rdist@usc.edu Message-Id: <01H8YA7VMRDE0069UE@INDYVAX.IUPUI.EDU> X-Vms-To: IN%"rdist@usc.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I would like to know if anyone has compiled rdist under Solaris2.3? If so, what changes were neccessary to compile successfuly? Cornell Tribbet Computer Systems Engineer Indiana Univ.-Purdue Univ. at Indianapolis ------------------------------------------ Ctribbet@IndyVax.Iupui.Edu Phone: (317)274-9734 Fax: (317)274-9742 From mcooper@ucs.usc.edu Wed Feb 16 15:01:39 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14442; Wed, 16 Feb 94 15:01:39 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id PAA02433; Wed, 16 Feb 1994 15:01:05 -0800 Sender: "Michael A. Cooper" Date: Wed, 16 Feb 94 15:01:05 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: t016479@voodoo.ch.swissbank.com (Sean Boran) Subject: Re: Summary: Rdist: FAQ / Future In-Reply-To: Your message of Tue, 15 Feb 94 09:20:30 +0100 Cc: rdist-dev@usc.edu Message-Id: > > Well, this is a summary of responses received. I have cut out non essential > text. > > Given what you can do with rdist, removing .rhosts doesn't help security. > I think that if rdistd used an "access list" file to decide whether to > accept a connection, it would improve security. (Something like "hosts.allow" > used by the tcpd inetd wrappers). > Because rdistd is invoked by rshd, it has no secure way of knowing the real IP address of the host originating the session. The originator does send it's hostname to rdistd as an rdist command for informational purposes only. mike From stssram@st.unocal.com Wed Feb 16 19:51:47 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25942; Wed, 16 Feb 94 19:51:47 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id TAA06592; Wed, 16 Feb 1994 19:51:45 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA29452; Wed, 16 Feb 94 19:51:44 PST Message-Id: <9402170351.AA29452@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Wed, 16 Feb 1994 19:51:43 -0800 Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: Rdist command line options and Distfiles It would appear that a lot of the new features in rdist-6.X are accessible only through the command line, not through the Distfile. In particular, -[Aa] for min inodes/disk space, -[lL] for logging options, and -t for timeout values. I don't really understand why this was done this way, particularly the logging, since nothing gets logged unless you give the appropriate command line option. It seems to me that this leads to always running rdist from a shell script, but I sort of thought the point of a Distfile was to keep all the rdist parameters together. Most old rdist options were accessible either on the command line or the "install" line in the Distfile. Is there a reason for this, or was it just an ease of implementation sort of thing? I'd like to try to add this back in in some manner. I recognize that all the options I mentioned take arguments, while the -o options do not. How about it? I'm willing to go into the code and do this myself if no one comes up with a reason I shouldn't. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From dbeusee@us.oracle.com Wed Feb 16 21:36:47 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29952; Wed, 16 Feb 94 21:36:47 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id VAA16111; Wed, 16 Feb 1994 21:36:42 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA03756; Wed, 16 Feb 94 21:34:45 PST Message-Id: <9402170534.AA03756@dbeusee.us.oracle.com> Date: Wed, 16 Feb 94 21:34:45 PST From: Don Beusee To: rdist-dev@usc.edu, stssram@st.unocal.com Subject: Re: Rdist command line options and Distfiles How can you decide on log formatting in an install directive? You cannot because some logging will occur before that point. Thats why they need to be command line options. I suppose the timeout would not work either - isn't the timer started before any install directives are executed? From stssram@st.unocal.com Wed Feb 16 20:05:38 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA02942; Wed, 16 Feb 94 20:05:38 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id UAA11679; Wed, 16 Feb 1994 20:07:22 -0800 Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25942; Wed, 16 Feb 94 19:51:47 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id TAA06592; Wed, 16 Feb 1994 19:51:45 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA29452; Wed, 16 Feb 94 19:51:44 PST Message-Id: <9402170351.AA29452@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Wed, 16 Feb 1994 19:51:43 -0800 Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: Rdist command line options and Distfiles Status: R It would appear that a lot of the new features in rdist-6.X are accessible only through the command line, not through the Distfile. In particular, -[Aa] for min inodes/disk space, -[lL] for logging options, and -t for timeout values. I don't really understand why this was done this way, particularly the logging, since nothing gets logged unless you give the appropriate command line option. It seems to me that this leads to always running rdist from a shell script, but I sort of thought the point of a Distfile was to keep all the rdist parameters together. Most old rdist options were accessible either on the command line or the "install" line in the Distfile. Is there a reason for this, or was it just an ease of implementation sort of thing? I'd like to try to add this back in in some manner. I recognize that all the options I mentioned take arguments, while the -o options do not. How about it? I'm willing to go into the code and do this myself if no one comes up with a reason I shouldn't. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From stssram@st.unocal.com Wed Feb 16 21:57:38 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00910; Wed, 16 Feb 94 21:57:38 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id VAA13817; Wed, 16 Feb 1994 21:57:37 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA02445; Wed, 16 Feb 94 21:57:35 PST Message-Id: <9402170557.AA02445@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Wed, 16 Feb 1994 21:57:34 -0800 In-Reply-To: Don Beusee "Re: Rdist command line options and Distfiles" (Feb 16, 21:34) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Don Beusee , rdist-dev@usc.edu Subject: Re: Rdist command line options and Distfiles On Feb 16, 21:34, Don Beusee wrote: } Subject: Re: Rdist command line options and Distfiles > How can you decide on log formatting in an install directive? You cannot > because some logging will occur before that point. Thats why they need to > be command line options. I suppose the timeout would not work either - isn't > the timer started before any install directives are executed? Ok, so I haven't looked at either the code or the logging stuff very carefully yet. I agree that some sorts of logging will occur outside of an install, but I'd really like to have the "change" and "notice" logging controllable from within a Distfile, and optionally different for each package. Sort of a vastly more powerful "notify" command. Obviously, some particular sorts of logging will not be controllable, as you say. Maybe the thing to do is upgrade the notify command instead of using the 6.0 logging functions as such. My reading of the man page is that the timeout is between responses from the remote server, not time to complete the install of the package. If that's the case, in principle the timeout period could be reset between any two responses, right? Oh well, time to dig into the code.... -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From rsalz@osf.org Thu Feb 17 05:43:52 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20041; Thu, 17 Feb 94 05:43:52 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA11017; Thu, 17 Feb 94 08:43:35 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA05034; Thu, 17 Feb 94 08:43:01 -0500 Date: Thu, 17 Feb 94 08:43:01 -0500 From: rsalz@osf.org Message-Id: <9402171343.AA05034@sulphur.osf.org> To: mcooper@usc.edu, t016479@voodoo.ch.swissbank.com (Sean Boran) Subject: Re: Summary: Rdist: FAQ / Future Cc: rdist-dev@usc.edu > Because rdistd is invoked by rshd, it has no secure way of knowing the > real IP address of the host originating the session. getpeername() on descriptor 0, followed by gethostbyaddr() and then do a gethostbyname() to make sure someone hasn't set up a lying ip-addr server. /r$ From neal@ctd.comsat.com Thu Feb 17 05:51:07 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20254; Thu, 17 Feb 94 05:51:07 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pX987-0002fOC; Thu, 17 Feb 94 08:50 EST Message-Id: Date: Thu, 17 Feb 94 08:50 EST From: neal@ctd.comsat.com (Neal Becker) To: rsalz@osf.org Cc: mcooper@usc.edu, t016479@voodoo.ch.swissbank.com (Sean Boran), rdist-dev@usc.edu Subject: Re: Summary: Rdist: FAQ / Future In-Reply-To: <9402171343.AA05034@sulphur.osf.org> References: <9402171343.AA05034@sulphur.osf.org> >>>>> "rsalz" == rsalz writes: >> Because rdistd is invoked by rshd, it has no secure way of >> knowing the real IP address of the host originating the >> session. rsalz> getpeername() on descriptor 0, followed by gethostbyaddr() rsalz> and then do a gethostbyname() to make sure someone hasn't rsalz> set up a lying ip-addr server. /r$ Maybe turn off source routing socketoption also? From Anthony.Datri@amd.com Thu Feb 17 07:36:07 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25142; Thu, 17 Feb 94 07:36:07 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02520 (5.67a/IDA-1.5+AMD for ); Thu, 17 Feb 1994 07:36:03 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA12924 (5.67a/IDA-1.5+AMD for ); Thu, 17 Feb 1994 07:36:01 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA07420; Thu, 17 Feb 94 09:36:00 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA07846; Thu, 17 Feb 94 09:36:12 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Thu, 17 Feb 1994 09:36:12 -0600 (CST) Message-Id: Date: Thu, 17 Feb 1994 09:36:12 -0600 (CST) From: Anthony Datri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: Re: Rdist command line options and Distfiles In-Reply-To: <9402170534.AA03756@dbeusee.us.oracle.com> References: <9402170534.AA03756@dbeusee.us.oracle.com> One thing I'd like to see is the annoying "rdist starting up for host" messages disappear. ======================================================================8--< From andym@dsbc.icl.co.uk Thu Feb 17 08:06:08 1994 Return-Path: Received: from relay1.pipex.net by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26236; Thu, 17 Feb 94 08:06:08 PST Received: from Q.icl.co.uk by relay1.pipex.net with SMTP (PP) id <11643-0@relay1.pipex.net>; Thu, 17 Feb 1994 15:50:15 +0000 Received: from eccles.dsbc.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server) id AA16045; Thu, 17 Feb 94 15:52:18 GMT Received: from cerberus.dsbc.icl.co.uk on eccles.dsbc.icl.co.uk id AA10545; Thu, 17 Feb 94 15:50:18 GMT Received: by cerberus.dsbc.icl.co.uk (4.1/rpa-1.3) id AA23394; Thu, 17 Feb 94 15:53:35 GMT From: andym@dsbc.icl.co.uk (Andrew D Milligan) Message-Id: <9402171553.AA23394@cerberus.dsbc.icl.co.uk> Subject: UNSUBSCRIBE To: rdist-dev@usc.edu Date: Thu, 17 Feb 1994 15:53:35 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 12 UNSUBSCRIBE From heather@sdcc3.ucsd.edu Thu Feb 17 08:54:57 1994 Return-Path: Received: from ucsd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27905; Thu, 17 Feb 94 08:54:57 PST Received: from sdcc14.UCSD.EDU by ucsd.edu; id IAA29261 sendmail 8.6.4/UCSD-2.2-sun via SMTP Thu, 17 Feb 1994 08:54:50 -0800 From: heather@sdcc3.ucsd.edu Received: from [132.239.50.38] (camelot.ucsd.edu) by sdcc14.UCSD.EDU (4.1/UCSDGENERIC.4) id AA00689 to rdist-dev@usc.edu; Thu, 17 Feb 94 08:54:47 PST Date: Thu, 17 Feb 94 08:54:46 PST Message-Id: <9402171654.AA00689@sdcc14.UCSD.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Anthony Datri , rdist-dev@usc.edu Subject: Re: Rdist command line options and Distfiles Can't you? I have it set to local5.info in syslog.conf. I think if I made it local5.notice, I wouldn't get a syslog full of lines of rdist starting ( logged every 20 minutes because that is how we keep somethings in sync). I keep it turned on at such a verbose level because I want to know if someone tries to run rdist from/to one of the workstation labs that I manage. I separated it from the DAEMON facility and made it LOCAL5, because I wanted to put the output in a separate file. It makes reading the output from the daemon facility easier. I have the diffs mailed to me every day from all of my systems and it is a lot of work to skim through them for things that shouldn't be happening or attempts to crack my systems. --Heather At 9:36 AM 2/17/94 -0600, Anthony Datri wrote: >One thing I'd like to see is the annoying "rdist starting up for host" >messages disappear. > >======================================================================8--< From mcooper@ucs.usc.edu Thu Feb 17 10:17:14 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01691; Thu, 17 Feb 94 10:17:14 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id KAA07225; Thu, 17 Feb 1994 10:17:10 -0800 Sender: "Michael A. Cooper" Date: Thu, 17 Feb 94 10:17:10 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: Anthony Datri Cc: rdist-dev@usc.edu Subject: Re: Rdist command line options and Distfiles In-Reply-To: Your message of Thu, 17 Feb 1994 09:36:12 -0600 (CST) Message-Id: > One thing I'd like to see is the annoying "rdist starting up for host" > messages disappear. > > ======================================================================8--< > > They are disabled by default in the next release. You can enable just those messages by enabled a new logging level called "verbose". mike From jor@advtech.uswest.com Thu Feb 17 19:11:20 1994 Return-Path: Received: from uswat.advtech.uswest.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26460; Thu, 17 Feb 94 19:11:20 PST Received: from moab.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA20126 (5.67b/IDA-1.5 for ); Thu, 17 Feb 1994 20:11:17 -0700 Received: by moab.advtech.uswest.com (advtech.uswest.com) id AA01907 (4.1/at-generic.8Nov93); Thu, 17 Feb 94 20:11:15 MST Date: Thu, 17 Feb 94 20:11:15 MST From: Joel Rem Message-Id: <9402180311.AA01907@moab.advtech.uswest.com> To: rdist-dev@usc.edu Subject: updating executing binaries Being new to rdist I wonder what is meant in the man page by: ... and can update programs that are executing. Does this mean I can update /usr/lib/sendmail and sendmail will not die on the machine with where /usr/lib is a local disk as well as any clients that mount /usr/lib from this machine? I assume I still would need to restart sendmail on all machines to start using the new binary? Does anyone use rdist in this compacity or am I better off running a script? mv /usr/lib/sendmail /usr/lib/sendmail.old cp ../sendmail.new /usr/lib/sendmail restart sendmail on all affected machines Joel Rem jor@advtech.uswest.com USWEST AT ph:(303)541-6308 From dbeusee@us.oracle.com Thu Feb 17 20:05:31 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28565; Thu, 17 Feb 94 20:05:31 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id UAA10643; Thu, 17 Feb 1994 20:05:29 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA19134; Thu, 17 Feb 94 20:03:31 PST Message-Id: <9402180403.AA19134@dbeusee.us.oracle.com> Date: Thu, 17 Feb 94 20:03:31 PST From: Don Beusee To: jor@advtech.uswest.com, rdist-dev@usc.edu Subject: Re: updating executing binaries What I do is rdist running executables as .NEW: (/usr/lib/sendmail.NEW /usr/lib/sendmail.cf) -> host1 install; cmdspecial "mv /usr/lib/sendmail /usr/lib/sendmail.old; mv /usr/lib/sendmail.NEW /usr/lib/sendmail; kill `cat /etc/sendmail.pid`; sleep 2; /usr/lib/sendmail -bd -q15m"; Someday rdist may have prespecial, then you can rename current executable, rdist /usr/lib/sendmail, then cmdspecial to restart sendmail. Regards, Don. From jor@advtech.uswest.com Thu Feb 17 19:42:40 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA18942; Thu, 17 Feb 94 19:42:39 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id TAA09386; Thu, 17 Feb 1994 19:44:34 -0800 Received: from uswat.advtech.uswest.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26460; Thu, 17 Feb 94 19:11:20 PST Received: from moab.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA20126 (5.67b/IDA-1.5 for ); Thu, 17 Feb 1994 20:11:17 -0700 Received: by moab.advtech.uswest.com (advtech.uswest.com) id AA01907 (4.1/at-generic.8Nov93); Thu, 17 Feb 94 20:11:15 MST Date: Thu, 17 Feb 94 20:11:15 MST From: Joel Rem Message-Id: <9402180311.AA01907@moab.advtech.uswest.com> To: rdist-dev@usc.edu Subject: updating executing binaries Status: R Being new to rdist I wonder what is meant in the man page by: ... and can update programs that are executing. Does this mean I can update /usr/lib/sendmail and sendmail will not die on the machine with where /usr/lib is a local disk as well as any clients that mount /usr/lib from this machine? I assume I still would need to restart sendmail on all machines to start using the new binary? Does anyone use rdist in this compacity or am I better off running a script? mv /usr/lib/sendmail /usr/lib/sendmail.old cp ../sendmail.new /usr/lib/sendmail restart sendmail on all affected machines Joel Rem jor@advtech.uswest.com USWEST AT ph:(303)541-6308 From stssram@st.unocal.com Thu Feb 17 20:38:36 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29964; Thu, 17 Feb 94 20:38:36 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id UAA02244; Thu, 17 Feb 1994 20:38:33 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA18291; Thu, 17 Feb 94 20:38:29 PST Message-Id: <9402180438.AA18291@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Thu, 17 Feb 1994 20:38:29 -0800 In-Reply-To: Don Beusee "Re: updating executing binaries" (Feb 17, 20:03) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Don Beusee , rdist-dev@usc.edu Subject: Re: updating executing binaries On Feb 17, 20:03, Don Beusee wrote: } Subject: Re: updating executing binaries > What I do is rdist running executables as .NEW: > > (/usr/lib/sendmail.NEW /usr/lib/sendmail.cf) -> host1 > install; > cmdspecial "mv /usr/lib/sendmail /usr/lib/sendmail.old; mv /usr/lib/sendmail.NEW /usr/lib/sendmail; kill `cat /etc/sendmail.pid`; sleep 2; /usr/lib/sendmail -bd -q15m"; > > Someday rdist may have prespecial, then you can rename current executable, > rdist /usr/lib/sendmail, then cmdspecial to restart sendmail. I use the savetargets option on rdist 6.1 if there's a chance the files may be NFS mounted. That basically gets rid of the first "mv" in your cmdspecial. Is there some reason you don't, or does this practice predate savetargets? I use this mainly to distribute new versions of X11 to remote fileservers, so I'd have to use one heck of a find and replace script if I didn't use savetargets. As a side note, remember that you really ought to use "except_pat \\.OLD\$;" if you use savetargets for large hierarchies! -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From jay@silence.princeton.nj.us Thu Feb 17 21:39:00 1994 Return-Path: Received: from Princeton.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01797; Thu, 17 Feb 94 21:39:00 PST Received: by Princeton.EDU (5.65b/2.105/princeton) id AA24490; Thu, 17 Feb 94 23:15:19 -0500 Received: from localhost by silence.princeton.nj.us (8.6.5/1.101) id XAA22291; Thu, 17 Feb 1994 23:08:07 -0500 Date: Thu, 17 Feb 1994 23:08:07 -0500 From: Jay Plett Message-Id: <199402180408.XAA22291@silence.princeton.nj.us> To: jor@advtech.uswest.com, rdist-dev@usc.edu Subject: Re: updating executing binaries Reply-To: jay@Princeton.EDU > Does this mean I can update /usr/lib/sendmail and sendmail will not > die on the machine with where /usr/lib is a local disk as well as any > clients that mount /usr/lib from this machine? sendmail will certainly die on NFS clients of the rdist slave. It might be nice if rdist offered an option for files that are likely to be executing when rdist runs. Instead of removing files that are listed as critical, it would rename them to, say, "#sendmail". Then NFS-mounted clients could keep executing. Either rdist itself or a separate cron job could remove files named "#*" after some period of time. Of course, this would not protect daemons like sendmail, since they will run forever. But it would take care of the more common cases, like dynamic libraries and frequently executed files. ...jay From stssram@st.unocal.com Thu Feb 17 22:12:19 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03068; Thu, 17 Feb 94 22:12:19 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id WAA07022; Thu, 17 Feb 1994 22:12:17 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA19333; Thu, 17 Feb 94 22:12:16 PST Resent-Message-Id: <9402180612.AA19333@st.unocal.com> Message-Id: <9402180612.AA19333@st.unocal.com> Resent-From: stssram@st.unocal.com (Bob Myers) Resent-Date: Thu, 17 Feb 1994 22:12:16 -0800 Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) Resent-To: rdist-dev@usc.edu From: stssram@st.unocal.com (Bob Myers) Date: Thu, 17 Feb 1994 20:13:32 -0800 In-Reply-To: Joel Rem "updating executing binaries" (Feb 17, 20:11) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Joel Rem Subject: Re: updating executing binaries On Feb 17, 20:11, Joel Rem wrote: } Subject: updating executing binaries > > Being new to rdist I wonder what is meant in the man page by: > > ... and can update programs that are executing. > > Does this mean I can update /usr/lib/sendmail and sendmail will not > die on the machine with where /usr/lib is a local disk as well as any > clients that mount /usr/lib from this machine? I assume I still would > need to restart sendmail on all machines to start using the new binary? > Does anyone use rdist in this compacity or am I better off running > a script? NFS disks are different from UFS (local) disks. "rdist", without any special commands, can update UFS executables without affecting running programs because it does not copy over the inode, but builds a new one, unlinks the old pathname, and renames the new copy to the old pathname. The UFS does not delete the replaced inode from the disk until all programs that have opened it close it (including running instances of a program). Thus, if /usr/lib/sendmail is local to a machine, and you rdist a new copy, rdist will create a new copy called something like rdist3324 (a unique filename), unlink sendmail, and then rename rdist3324 to sendmail. The currently running sendmail program no longer is in the filesystem as such, but the inode is still on disk. NFS is different, since it is a stateless protocol. The NFS server has no idea if programs are running using that inode or not, and in fact treat it as if the file is closed. Thus, you would actually delete the inode for sendmail in this case, and the sendmail program would crash. But wait! With rdist-6.X, there's a solution. If you use the -osavetargets option, the old copy of an rdisted file is kept, with the extension .OLD added. It's equivalent to this: mv sendmail sendmail.OLD mv rdist3324 sendmail Be sure not to delete the .OLD file (or send another update via rdist!) until all running sendmails have been restarted. Of course, you can also use a "special" or "cmdspecial" command in your Distfile to restart sendmail after distributing it. Yes, I use rdist in this capacity. *My* primary use is distributing new versions of X11 to remote NFS fileservers within the company, but other people in my organization use it for things like sendmail. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From dbeusee@us.oracle.com Fri Feb 18 01:43:44 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11175; Fri, 18 Feb 94 01:43:44 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id BAA27570; Fri, 18 Feb 1994 01:43:40 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22106; Fri, 18 Feb 94 01:41:39 PST Message-Id: <9402180941.AA22106@dbeusee.us.oracle.com> Date: Fri, 18 Feb 94 01:41:39 PST From: Don Beusee To: rdist-dev@usc.edu, stssram@st.unocal.com Subject: Re: updating executing binaries savetargets would be fine if you want it to rename every file in your rdist. I suppose the sample distfile I provided could be written as follows: /usr/lib/sendmail -> host1 install -osavetargets; special "kill `cat /etc/sendmail.pid`; sleep 2; /usr/lib/sendmail -bd -q15m"; /usr/lib/sendmail.cf -> host1 install; From stssram@st.unocal.com Thu Feb 17 20:39:21 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA19384; Thu, 17 Feb 94 20:39:20 PST Received: from unogate.unocal.com by gatekeeper.us.oracle.com with ESMTP (8.6.4/37.7) id UAA12155; Thu, 17 Feb 1994 20:41:11 -0800 Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id UAA02244; Thu, 17 Feb 1994 20:38:33 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA18291; Thu, 17 Feb 94 20:38:29 PST Message-Id: <9402180438.AA18291@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Thu, 17 Feb 1994 20:38:29 -0800 In-Reply-To: Don Beusee "Re: updating executing binaries" (Feb 17, 20:03) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Don Beusee , rdist-dev@usc.edu Subject: Re: updating executing binaries Status: R On Feb 17, 20:03, Don Beusee wrote: } Subject: Re: updating executing binaries > What I do is rdist running executables as .NEW: > > (/usr/lib/sendmail.NEW /usr/lib/sendmail.cf) -> host1 > install; > cmdspecial "mv /usr/lib/sendmail /usr/lib/sendmail.old; mv /usr/lib/sendmail.NEW /usr/lib/sendmail; kill `cat /etc/sendmail.pid`; sleep 2; /usr/lib/sendmail -bd -q15m"; > > Someday rdist may have prespecial, then you can rename current executable, > rdist /usr/lib/sendmail, then cmdspecial to restart sendmail. I use the savetargets option on rdist 6.1 if there's a chance the files may be NFS mounted. That basically gets rid of the first "mv" in your cmdspecial. Is there some reason you don't, or does this practice predate savetargets? I use this mainly to distribute new versions of X11 to remote fileservers, so I'd have to use one heck of a find and replace script if I didn't use savetargets. As a side note, remember that you really ought to use "except_pat \\.OLD\$;" if you use savetargets for large hierarchies! -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From dbeusee@us.oracle.com Fri Feb 18 01:50:00 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11435; Fri, 18 Feb 94 01:50:00 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id BAA28007; Fri, 18 Feb 1994 01:49:50 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA22139; Fri, 18 Feb 94 01:47:52 PST Message-Id: <9402180947.AA22139@dbeusee.us.oracle.com> Date: Fri, 18 Feb 94 01:47:52 PST From: Don Beusee To: jor@advtech.uswest.com, stssram@st.unocal.com Subject: Re: updating executing binaries Cc: rdist-dev@usc.edu At least half of the platforms protect against someone removing executables that are currently running. You cannot copy into them either (open-write is not allowed). So the only things that work is -savetargets or mv. Not very many platforms will actually cause the running process to die (I have not seen one die yet, and I've got many types of platforms here). The platforms that allow rm do not loose the inode on the filesystem until all running processes have terminated. From stssram@st.unocal.com Thu Feb 17 22:24:10 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA20242; Thu, 17 Feb 94 22:24:09 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id WAA17076; Thu, 17 Feb 1994 22:25:32 -0800 Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03068; Thu, 17 Feb 94 22:12:19 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id WAA07022; Thu, 17 Feb 1994 22:12:17 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA19333; Thu, 17 Feb 94 22:12:16 PST Resent-Message-Id: <9402180612.AA19333@st.unocal.com> Message-Id: <9402180612.AA19333@st.unocal.com> Resent-From: stssram@st.unocal.com (Bob Myers) Resent-Date: Thu, 17 Feb 1994 22:12:16 -0800 Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) Resent-To: rdist-dev@usc.edu From: stssram@st.unocal.com (Bob Myers) Date: Thu, 17 Feb 1994 20:13:32 -0800 In-Reply-To: Joel Rem "updating executing binaries" (Feb 17, 20:11) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Joel Rem Subject: Re: updating executing binaries Status: R On Feb 17, 20:11, Joel Rem wrote: } Subject: updating executing binaries > > Being new to rdist I wonder what is meant in the man page by: > > ... and can update programs that are executing. > > Does this mean I can update /usr/lib/sendmail and sendmail will not > die on the machine with where /usr/lib is a local disk as well as any > clients that mount /usr/lib from this machine? I assume I still would > need to restart sendmail on all machines to start using the new binary? > Does anyone use rdist in this compacity or am I better off running > a script? NFS disks are different from UFS (local) disks. "rdist", without any special commands, can update UFS executables without affecting running programs because it does not copy over the inode, but builds a new one, unlinks the old pathname, and renames the new copy to the old pathname. The UFS does not delete the replaced inode from the disk until all programs that have opened it close it (including running instances of a program). Thus, if /usr/lib/sendmail is local to a machine, and you rdist a new copy, rdist will create a new copy called something like rdist3324 (a unique filename), unlink sendmail, and then rename rdist3324 to sendmail. The currently running sendmail program no longer is in the filesystem as such, but the inode is still on disk. NFS is different, since it is a stateless protocol. The NFS server has no idea if programs are running using that inode or not, and in fact treat it as if the file is closed. Thus, you would actually delete the inode for sendmail in this case, and the sendmail program would crash. But wait! With rdist-6.X, there's a solution. If you use the -osavetargets option, the old copy of an rdisted file is kept, with the extension .OLD added. It's equivalent to this: mv sendmail sendmail.OLD mv rdist3324 sendmail Be sure not to delete the .OLD file (or send another update via rdist!) until all running sendmails have been restarted. Of course, you can also use a "special" or "cmdspecial" command in your Distfile to restart sendmail after distributing it. Yes, I use rdist in this capacity. *My* primary use is distributing new versions of X11 to remote NFS fileservers within the company, but other people in my organization use it for things like sendmail. -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From jay@silence.princeton.nj.us Fri Feb 18 07:34:40 1994 Return-Path: Received: from Princeton.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25683; Fri, 18 Feb 94 07:34:40 PST Received: by Princeton.EDU (5.65b/2.105/princeton) id AA19455; Fri, 18 Feb 94 09:38:40 -0500 Received: from localhost by silence.princeton.nj.us (8.6.5/1.101) id BAA22944; Fri, 18 Feb 1994 01:20:31 -0500 Date: Fri, 18 Feb 1994 01:20:31 -0500 From: Jay Plett Message-Id: <199402180620.BAA22944@silence.princeton.nj.us> To: jor@advtech.uswest.com, rdist-dev@usc.edu Subject: Re: updating executing binaries Reply-To: jay@Princeton.EDU I said: > It might be nice if rdist offered an option... Now I will wipe the egg off my face and promise to read the manpage 7 times before posting again. I didn't remember savetargets. Oh, well. ...jay From Anthony.Datri@amd.com Sat Feb 19 12:25:45 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02923; Sat, 19 Feb 94 12:25:45 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA08590 (5.67a/IDA-1.5+AMD for ); Sat, 19 Feb 1994 12:25:42 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA04828 (5.67a/IDA-1.5+AMD for ); Sat, 19 Feb 1994 12:25:41 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA26121; Sat, 19 Feb 94 14:25:40 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA12438; Sat, 19 Feb 94 14:25:52 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Sat, 19 Feb 1994 14:25:52 -0600 (CST) Message-Id: Date: Sat, 19 Feb 1994 14:25:52 -0600 (CST) From: Anthony Datri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: rdistd bites the dust on busy text files? Rdist 6.1.b2, Sun 4/490 SunOS 4.1.2 master; various slaves, including HP9000s700's running 9.01. I recently built new AMD binaries for the HP's, and disted them out without incident at first -- the remote text files were busy, and preserved as amd.OLD just fine. Subsequent dists give me this, though: benson: /usr/local/bin.hp9000s700/amd.upl75/amd: updating benson: /usr/local/etc/amd.upl75/amd.OLD: remove failed: Text file busy At this point rdist wedges. rdistd -S is still running on the slave though, but eventually I get benson: LOCAL ERROR: Response time out and no subsequent packages get pushed. Any ideas? ======================================================================8--< From rouilj@cs.umb.edu Sat Feb 19 13:07:31 1994 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04185; Sat, 19 Feb 94 13:07:31 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA28007 (5.65c/IDA-1.4.4 for ); Sat, 19 Feb 1994 16:07:26 -0500 Message-Id: <199402192107.AA28007@cs.umb.edu> To: Anthony Datri Cc: rdist-dev@usc.edu Subject: Re: rdistd bites the dust on busy text files? In-Reply-To: Your message of "Sat, 19 Feb 1994 14:25:52 CST." Date: Sat, 19 Feb 1994 16:07:25 -0500 From: "John P. Rouillard" In message , Anthony Datri writes: > I recently built new AMD binaries for the HP's, and disted them out > without incident at first -- the remote text files were busy, and > preserved as amd.OLD just fine. Subsequent dists give me this, though: > > benson: /usr/local/bin.hp9000s700/amd.upl75/amd: updating > benson: /usr/local/etc/amd.upl75/amd.OLD: remove failed: Text file busy > > At this point rdist wedges. rdistd -S is still running on the slave > though, but eventually I get > > benson: LOCAL ERROR: Response time out > > and no subsequent packages get pushed. Hmm, I have had savetargets fail to move the file, but they kept on running right along. Is it possible that it got wedged trying to remove the amd file after its attempt to rename amd to amd.OLD failed because some host was using AMD.old? > Any ideas? Well how about changinging savetargets so that it takes an optional arg that is the extention to use when saving the target. Better yet would be an "savetargetalways" that looks for the existance of a .OLD, and iterates through suffixes of .OLD.1 .OLD.2 ... until it finds an unused filename to save the target to. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Sat Feb 19 16:12:50 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09354; Sat, 19 Feb 94 16:12:50 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id QAA21151; Sat, 19 Feb 1994 16:12:05 -0800 Received: by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA13862; Sat, 19 Feb 94 16:10:05 PST Message-Id: <9402200010.AA13862@dbeusee.us.oracle.com> Date: Sat, 19 Feb 94 16:10:05 PST From: Don Beusee To: aad@lovecraft.amd.com, rouilj@terminus.cs.umb.edu Subject: Re: rdistd bites the dust on busy text files? Cc: rdist-dev@usc.edu Why don't we save ourselves the headache and just call the file: .RDISTSAVE.yymmddhhmiss Before saving this file, rdist could remove $REMFILE.RDISTSAVE.* to cleanup old copies (unless some rdist option was specified like -osavetargetalways). Something for the TODO list. From rouilj@cs.umb.edu Sat Feb 19 13:19:34 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (Oracle 1.12/37.7) id AA12334; Sat, 19 Feb 94 13:19:34 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7) id NAA15397; Sat, 19 Feb 1994 13:21:24 -0800 Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04185; Sat, 19 Feb 94 13:07:31 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA28007 (5.65c/IDA-1.4.4 for ); Sat, 19 Feb 1994 16:07:26 -0500 Message-Id: <199402192107.AA28007@cs.umb.edu> To: Anthony Datri Cc: rdist-dev@usc.edu Subject: Re: rdistd bites the dust on busy text files? In-Reply-To: Your message of "Sat, 19 Feb 1994 14:25:52 CST." Date: Sat, 19 Feb 1994 16:07:25 -0500 From: "John P. Rouillard" Status: R In message , Anthony Datri writes: > I recently built new AMD binaries for the HP's, and disted them out > without incident at first -- the remote text files were busy, and > preserved as amd.OLD just fine. Subsequent dists give me this, though: > > benson: /usr/local/bin.hp9000s700/amd.upl75/amd: updating > benson: /usr/local/etc/amd.upl75/amd.OLD: remove failed: Text file busy > > At this point rdist wedges. rdistd -S is still running on the slave > though, but eventually I get > > benson: LOCAL ERROR: Response time out > > and no subsequent packages get pushed. Hmm, I have had savetargets fail to move the file, but they kept on running right along. Is it possible that it got wedged trying to remove the amd file after its attempt to rename amd to amd.OLD failed because some host was using AMD.old? > Any ideas? Well how about changinging savetargets so that it takes an optional arg that is the extention to use when saving the target. Better yet would be an "savetargetalways" that looks for the existance of a .OLD, and iterates through suffixes of .OLD.1 .OLD.2 ... until it finds an unused filename to save the target to. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From mcooper@ucs.usc.edu Wed Mar 2 10:28:50 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18290; Wed, 2 Mar 94 10:28:50 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id KAA04532 for rdist-dev@usc.edu; Wed, 2 Mar 1994 10:28:49 -0800 Sender: "Michael A. Cooper" Date: Wed, 2 Mar 94 10:28:48 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: Upcoming new release of rdist Message-Id: A new release of rdist, 6.1beta.3, will hopefully be available soon. The release is almost all bug fixes, except for one major new feature. The new rdist will no longer require being setuid to "root". This is possible because the new rdist uses rsh(1c), the BSD remote shell program, to make the connection to rdistd on the remote host. Many thanks to Chris Siebenmann and John DiMarco who came up with an rsh version of rcmd() that makes this possible. There is a small price to pay for using the rsh program method. That price is in added connection startup time associated with the fork'ing of rsh. For each open connection, you also have 2 rsh processes doing I/O between rdist and the remote host. If you still want to use the traditional rcmd() method, you can compile rdist with DIRECT_RCMD defined and install rdist setuid root and it should still work as before. Before I release 6.1beta.3, I need to make sure that as many supported platforms as possible have the correct pathname for rsh. This is important because some systems have an "rsh" that is the "restricted shell" program and have renamed the remote shell command to be something else. If your OS has the remote shell command in a location other than /usr/ucb/rsh, please send me the full pathname to the command as well as your OS name and version. mike From raeburn@cygnus.com Wed Mar 2 13:21:52 1994 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26938; Wed, 2 Mar 94 13:21:52 PST Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwfnp13924; Wed, 2 Mar 94 16:20:13 -0500 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA14679; Wed, 2 Mar 94 13:20:02 PST From: raeburn@cygnus.com (Ken Raeburn) Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA12733; Wed, 2 Mar 94 16:20:01 EST Date: Wed, 2 Mar 94 16:20:01 EST Message-Id: <9403022120.AA12733@tweedledumb.cygnus.com> Received: by cambridge.cygnus.com (4.1/SMI-4.1) id AA00568; Wed, 2 Mar 94 16:19:58 EST To: mcooper@usc.edu Cc: rdist-dev@usc.edu In-Reply-To: "Michael A. Cooper"'s message of Wed, 2 Mar 94 10:28:48 PST Subject: Re: Upcoming new release of rdist Date: Wed, 2 Mar 94 10:28:48 PST From: "Michael A. Cooper" [... rdist will invoke rsh ...] Before I release 6.1beta.3, I need to make sure that as many supported platforms as possible have the correct pathname for rsh. This is important because some systems have an "rsh" that is the "restricted shell" program and have renamed the remote shell command to be something else. If your OS has the remote shell command in a location other than /usr/ucb/rsh, please send me the full pathname to the command as well as your OS name and version. It would be convenient if the rsh pathname were trivially configurable, and if path-searching were permitted if a pathname was not given. The reason I want this is so I can use /usr/kerberos/bin/rsh without having to search for the pathname definitions used for each host I might build rdist on... (This only gets me Kerberos authentication, not encryption, with the MIT and Cygnus Kerberos 4 releases. I think Kevin Fall hacked BSD's version of rsh to do encryption too, but it hasn't been merged back into the MIT distribution.) From mcooper@ucs.usc.edu Wed Mar 2 15:10:49 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02604; Wed, 2 Mar 94 15:10:49 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id PAA06462; Wed, 2 Mar 1994 15:10:10 -0800 Sender: "Michael A. Cooper" Date: Wed, 2 Mar 94 15:10:09 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: raeburn@cygnus.com (Ken Raeburn) Cc: rdist-dev@usc.edu Subject: Re: Upcoming new release of rdist In-Reply-To: Your message of Wed, 2 Mar 94 16:20:01 EST Message-Id: > Date: Wed, 2 Mar 94 10:28:48 PST > From: "Michael A. Cooper" > > [... rdist will invoke rsh ...] > > Before I release 6.1beta.3, I need to make sure that as many supported > platforms as possible have the correct pathname for rsh. This is > important because some systems have an "rsh" that is the "restricted > shell" program and have renamed the remote shell command to be > something else. If your OS has the remote shell command in a location > other than /usr/ucb/rsh, please send me the full pathname to the > command as well as your OS name and version. > > It would be convenient if the rsh pathname were trivially configurable, > and if path-searching were permitted if a pathname was not given. The > reason I want this is so I can use /usr/kerberos/bin/rsh without having > to search for the pathname definitions used for each host I might build > rdist on... > > (This only gets me Kerberos authentication, not encryption, with the MIT > and Cygnus Kerberos 4 releases. I think Kevin Fall hacked BSD's version > of rsh to do encryption too, but it hasn't been merged back into the MIT > distribution.) > Sounds good, but it will have to wait until the next release. I'm only going to fix real bugs in 6.1 at this point. mike From dbeusee@us.oracle.com Wed Mar 2 16:34:03 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06758; Wed, 2 Mar 94 16:34:03 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id QAA29091; Wed, 2 Mar 1994 16:32:58 -0800 Received: by dbeusee.us.oracle.com (4.1/37.7) id AA11764; Wed, 2 Mar 94 16:30:44 PST Message-Id: <9403030030.AA11764@dbeusee.us.oracle.com> Date: Wed, 2 Mar 94 16:30:44 PST From: Don Beusee To: mcooper@usc.edu, raeburn@cygnus.com Subject: Re: Upcoming new release of rdist Cc: rdist-dev@usc.edu I think its already possible to specify rsh without a path if you want to reply on $PATH for the correct thing. Mike, I think it would be easy to change the -p option to support specification of rsh and rdistd: -p '/usr/bin/rsh $host /usr/local/bin/rdistd' You could even support an alternate user this way: -p '/usr/bin/rsh $host /usr/local/bin/rdistd -l rdistuser' Can you put this into 61b3? Regards, Don. From mcooper@skat.usc.edu Wed Mar 2 15:30:35 1994 Received: from gatekeeper.us.oracle.com by dbeusee.us.oracle.com (4.1/37.7) id AA10897; Wed, 2 Mar 94 15:30:34 PST Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id PAA24317; Wed, 2 Mar 1994 15:32:40 -0800 Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02604; Wed, 2 Mar 94 15:10:49 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id PAA06462; Wed, 2 Mar 1994 15:10:10 -0800 Sender: "Michael A. Cooper" Date: Wed, 2 Mar 94 15:10:09 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: raeburn@cygnus.com (Ken Raeburn) Cc: rdist-dev@usc.edu Subject: Re: Upcoming new release of rdist In-Reply-To: Your message of Wed, 2 Mar 94 16:20:01 EST Message-Id: Status: R > Date: Wed, 2 Mar 94 10:28:48 PST > From: "Michael A. Cooper" > > [... rdist will invoke rsh ...] > > Before I release 6.1beta.3, I need to make sure that as many supported > platforms as possible have the correct pathname for rsh. This is > important because some systems have an "rsh" that is the "restricted > shell" program and have renamed the remote shell command to be > something else. If your OS has the remote shell command in a location > other than /usr/ucb/rsh, please send me the full pathname to the > command as well as your OS name and version. > > It would be convenient if the rsh pathname were trivially configurable, > and if path-searching were permitted if a pathname was not given. The > reason I want this is so I can use /usr/kerberos/bin/rsh without having > to search for the pathname definitions used for each host I might build > rdist on... > > (This only gets me Kerberos authentication, not encryption, with the MIT > and Cygnus Kerberos 4 releases. I think Kevin Fall hacked BSD's version > of rsh to do encryption too, but it hasn't been merged back into the MIT > distribution.) > Sounds good, but it will have to wait until the next release. I'm only going to fix real bugs in 6.1 at this point. mike From mcooper@ucs.usc.edu Thu Mar 3 16:29:57 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00927; Thu, 3 Mar 94 16:29:57 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id QAA16770; Thu, 3 Mar 1994 16:29:49 -0800 Sender: "Michael A. Cooper" Date: Thu, 3 Mar 94 16:29:48 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: Don Beusee Cc: raeburn@cygnus.com, rdist-dev@usc.edu Subject: Re: Upcoming new release of rdist In-Reply-To: Your message of Wed, 2 Mar 94 16:30:44 PST Message-Id: Okay, okay. You can now specify the path to rsh either like -P /usr/bin/remsh or -P /usr/ucb/rsh:/usr/bin/remsh mike From neal@ctd.comsat.com Fri Mar 4 06:02:11 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27073; Fri, 4 Mar 94 06:02:11 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pcaSA-0002fOC; Fri, 4 Mar 94 09:02 EST Message-Id: Date: Fri, 4 Mar 94 09:02 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu, rdist-dev@usc.edu Subject: Re: Upcoming new release of rdist In-Reply-To: <9403022120.AA12733@tweedledumb.cygnus.com> References: <9403022120.AA12733@tweedledumb.cygnus.com> Don't forget that hpux uses remsh, not rsh. From neal@ctd.comsat.com Fri Mar 4 06:39:52 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27774; Fri, 4 Mar 94 06:39:52 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pcb2d-0002fOC; Fri, 4 Mar 94 09:39 EST Message-Id: Date: Fri, 4 Mar 94 09:39 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: rdist-dev@usc.edu Subject: Upcoming new release of rdist In-Reply-To: References: HPUX 9.01 /usr/bin/remsh From mcooper@ucs.usc.edu Fri Mar 4 18:27:45 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22999; Fri, 4 Mar 94 18:27:45 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id LAA23384 for real-rdist-announce@usc.edu; Fri, 4 Mar 1994 11:06:26 -0800 Sender: "Michael A. Cooper" Date: Fri, 4 Mar 94 11:06:25 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist version 6.1beta.3 released Message-Id: Rdist version 6.1beta.3 is now available via anonymous ftp from usc.edu as "/pub/rdist/rdist-6.1beta.3.tar.gz". The README file is appended below. See ChangeLog for a complete list of changes since 6.1beta.2. It's my hope that there are no major problems remaining in this release. If so, the next release will be a non-test version 6.1. mike Rdist Version 6.1beta 3/4/94 Michael Cooper University Computing Services University of Southern California mcooper@usc.edu GENERAL INFORMATION This is version 6.1beta of Rdist from USC. It is based on rdist from 4.3BSD (classic). It includes all fixes for all bugs known to the CSRG Berkeley folks. It has been running at USC for some time now on a wide variety of platforms. This version of rdist is not directly compatible with rdist distributed with 4.3BSD and subsequent vendor releases, but does indirectly provide full backward compatibility. See COMPATIBILITY below for details. The current version of rdist is available via anonymous ftp on usc.edu under /pub/rdist. The current version is always retrievable as file "/pub/rdist/rdist.tar.z". CHANGES/FEATURES This version of rdist does not need to be setuid "root" at all. Rdist now uses the rsh(1c) [remote command] program to make connections to remote hosts, instead of making the connection directly. This eliminates the need to be run as "root". Many thanks to Chris Siebenmann and John DiMarco who came up with an rsh version of rcmd() that makes this possible. This version supports automatic system determination and configuration for pre-ported platforms. This means that rdist knows how to completely configure and compile itself for a number of platforms. Users don't need to worry about modifying any files to compile on a supported platform. See the ChangeLog file for the real details. The end of the file contains the major new features compared to rdist classic. A paper titled "Overhauling Rdist for the '90s" from USENIX LISA VI is available for anonymous ftp on usc.edu as "/pub/rdist/overhaul.ps.z". PLATFORMS This version of rdist has been ported to most major and a number of not so major platforms. The list below is only a partial list. The complete list of supported platforms can be found by looking at all the config/os-*.h files. MACHINE TYPE OPERATING SYSTEM --------------- ---------------------------------- DEC MIPS Ultrix 4.2 DG AviiON DG/UX 5.4.x HP 9000/300 HP/UX 7.05 (HP cc) HP 9000/400 HP/UX 7.05 (HP cc) HP 9000/700 HP/UX 8.07 (HP cc, GCC 2.3.1) IBM RS6000 AIX 3.2 NeXTStep Mach 3.1 Sun-3 SunOS 4.1.1 Sun-4/SPARC SunOS 4.1.3, SunOS 5.3 (Solaris 2.3) COMPATIBILITY This version of rdist differs greatly from older versions (as distributed with 4.3BSD) in that the client and the server portions are seperated into two distinct programs, rdist and rdistd, respectively. The protocol used to communicate between the client and server has also been extensively modified. These two items make providing "builtin" compatibility very difficult. However, backwards compatibility is possible, provided you have a binary or source copy of the old rdist. The way the old rdist started a server rdist is to run "rdist -Server". If the new rdist is run with the "-Server" option, then it will exec a copy of the old rdist (usually /usr/old/rdist or /usr/ucb/oldrdist). In this way, you get compatibility with hosts running the old rdist attempting to rdist to a machine running new rdist. If your host running new rdist wants to rdist to a host running the old rdist, then it must run the old rdist program (/usr/old/rdist or /usr/ucb/oldrdist). The definition _PATH_OLDRDIST in "config/config.h" controls the location of the old rdist. If this is not defined, or the defined program does not exist at runtime, then rdist will print an error when run with the "-Server" option. INSTALLATION 1) Determine whether the local machine is running a supported OS by running the command "config/os-type". If the command reports the local OS is "unknown", then you cannot proceed until rdist is ported to the local system OS. (See the PORTING section). 2) Edit "Makefile.local" to override any of the default Makefile variables as defined in "mf/Makefile.var". Usually you just want to change BIN_DIR to be appropriate for your system. 3) You may also want to check "config/config.h" for any local changes you would like to make. 4) Run "make" to compile everything. 5) Run "make install" to install the binaries and "make install.man" to install the manual pages. BUG REPORTS Bug reports should be sent to "rdist-bugs@usc.edu". All bug reports should include: 1) The version of the rdist client and server you are running (use the -V option to rdist and rdistd) 2) The platform (machine + OS name + OS version) 3) A full description of the problem, including sample distfiles. 4) If you have a patch to fix the problem, a context diff (diff -c) of the original files vs. the fixed files RDIST MAIL LISTS There are two rdist mailling lists described below. PLEASE DO NOT SEND GENERAL QUESTIONS TO ANY OF THESE LISTS. LIST NAME SUBSCRIPTION ADDRESS DESCRIPTION --------------- ----------------------- ------------------------------------ rdist-announce rdist-announce-request Announcements about new versions of Rdist. rdist-dev rdist-dev-request Rdist developers mailling list. Discussion about rdist features, suggestions, bugs, etc. Will also receive all rdist-announce mail. Only those who are _SERIOUS_ about being an rdist developer should be on this list. To subscribe or unsubscribe, send email to the appropriate SUBSCRIPTION ADDRESS from above "@usc.edu". i.e. "rdist-dev-request@usc.edu" for the "rdist-dev" list. Archives are available for anonymous ftp from usc.edu as /pub/rdist/.archive PORTING There are a number of steps to take when porting rdist to a new OS. Here are some very rough guidelines for what to do. 1) Modify "config/os-type" to determine your OS type. Make sure you use a string that's not more than 9 characters so we don't exceed the 14 character filename limits on certain systems. 2) Copy "config/os-TEMPLATE.h" to "config/os-YOUR_OS.h" (YOUR_OS should be whatever you modified os-type to print) and modify it according to its comments. Consult "config/config-def.h" for lists of possible values. 3) Copy "config/mf.TEMPLATE" to "config/mf.YOUR_OS" and modify it according to the comments found there in. 4) Optionally modify "src/isexec.c" to add your OS specific code for determining if a file is a local binary executable. 5) Test it! 6) Send me your "os-YOUR_OS.h" and "mf.YOUR_OS" files, along with context diffs to any other files you changed. NOTES rcmd() vs. rsh(1c) By default rdist uses rsh(1c) to make connections to remote hosts. This has the advantage that rdist does not need to be setuid to "root". This eliminates most potential security holes. It has the disadvantage that it takes slightly more time for rdist to connect to a remote host due to the added overhead of doing a fork() and then running the rsh(1c) command. If you wish to have rdist call the rcmd() function directly and avoid using rsh(1c) all together, then you should add "-DDIRECT_RCMD" to $(DEFS_LOCAL) and "RDIST_MODE = 4555" in "Makefile.local". You may need to do this if your system does not have the rsh(1c) command. HP/UX All of this information on HP/UX is third-hand. I don't have access to any HP/UX machines to test rdist on. Unlike HPUX version 7, version 8 does not come standard with yacc which is now part of the C/ANSI C Development Bundle. If that bundle is on the system, then rdist compiles fine with the changes to the Makefile to include regex.o and strcasecmp.o. If you don't have yacc and instead use the GNU bison in the yacc mode (-y option) it compiles fine but needs to have the PW library included (-lPW) in order to find an alloca.o when linking. The regex that is part of the HPUX C library is not compatible with the BSD style regex that rdist uses. Someone who leaves regex.o out of the MISSINGOBJS line in the Makefile because they noticed a regex(3) in the HPUX manual set is going to have a problem. OLD rcmd() LIBRARY BUG Very Old 4.2BSD-based Unix systems may have a bug in their rcmd() library function. The bug allowed a user process to run out of file descriptors if too many connection attempts failed. The problem is that the socket would never be closed if the connect() failed. This could eventually lead to running out of file descriptors if enough connections failed. Most current Unix's like SunOS 4.0.3 and later have this fixed. Here is a diff to (I think) the SunOS 3.5 rcmd() to fix the problem: *************** *** 51,56 **** --- 65,71 ---- timo *= 2; goto retry; } + (void) close(s); perror(hp->h_name); return (-1); } RCS INFO This is rcs info for this file: $Id: README,v 6.18 1994/02/24 22:26:05 mcooper Exp mcooper $ From tmoore@fievel.DaytonOH.NCR.COM Tue Mar 8 08:36:56 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03637; Tue, 8 Mar 94 08:36:56 PST Message-Id: <9403081636.AA03637@usc.edu> Subject: Still having problems with linked files To: rdist-dev@usc.edu (Rdist Development Group) Date: Tue, 8 Mar 1994 11:36:52 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 21605 I had inquired about this previously and at that time there were a flurry of patches flying about that could effect this. Since things seem a bit more stable at this time, I decided to resurface it. I picked up the rdist-6.1beta.3.tar.gz file and compiled it on my NCR System 3000. I had hoped that the problem I was having with linked files would be fixed. No such luck. Here is my test scenario: 1. Create a directory (testdir1) containing a file (testfile1) and a hard link to it (linkfile1). 2. Create a directory (testdir2) containing a file (testfile2) and a hard link to it (linkfile2). 3. Try to update a remote host with the following Distfile. HOST = beavis.DaytonOH.NCR.COM ( testdir1 testdir2 ) -> ${HOST} install /tmp ; The directories testdir1 and testdir2 will be made. The files testfile1 and testfile2 will be installed. The installation of the files linkfile1 and linkfile2 will fail. The software is attempting to link /tmp/testfile1 to /tmp/testdir1/linkfile1 on the remote system. Can anyone enlighten me as to what the problem is? I have included the debug output below. -- Tom Moore, Electronic Information Interchange ./rdist -D -ofollow,younger -f Distfile.test2 Version 6.1beta.3 - Protocol Version 6, Release 6.1beta, Patch level 3 fievel: Current message logging config: fievel: stdout=change,info,notice,nerror,ferror,warning,verbose,all,debug fievel: file= fievel: syslog=,nerror,ferror,all fievel: notify=change,info,notice,nerror,ferror,warning,verbose,all fievel: makenl(beavis.DaytonOH.NCR.COM) fievel: lookup(HOST, 1, 80a7f94) fievel: makenl(testdir1) fievel: makenl(testdir2) fievel: makenl(${HOST}) fievel: makenl(/tmp) fievel: expand(80a7fdc, 1) start, list = ( /tmp ) fievel: makenl(null) fievel: insert((null), 80a7fa0, 80a7fc4, 80a8c98) start, files = ( testdir1 testdir2 ) fievel: expand(80a7fa0, 3) start, list = ( testdir1 testdir2 ) fievel: makenl(null) fievel: makenl(null) fievel: expand(80a7fc4, 7) start, list = ( ${HOST} ) fievel: lookup(HOST, 0, 0) fievel: makenl(null) fievel: addchild() start fievel: addchild() created 'beavis.DaytonOH.NCR.COM' pid 20356 fd 9 (active=1) fievel: spawn() Forked child 20356 for host beavis.DaytonOH.NCR.COM active = 1 fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 204 bytes] beavis.DaytonOH.NCR.COM: doarrow(80a7ff4, beavis.DaytonOH.NCR.COM, 80a8c98) start beavis.DaytonOH.NCR.COM: makeconn(beavis.DaytonOH.NCR.COM) beavis.DaytonOH.NCR.COM: updating host beavis.DaytonOH.NCR.COM fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 248 bytes] beavis.DaytonOH.NCR.COM: Created notify temp file '/tmp/rdista004y4' beavis.DaytonOH.NCR.COM: local user = root remote user = root beavis.DaytonOH.NCR.COM: Remote command = 'rdistd -S' beavis.DaytonOH.NCR.COM: Remote shell command = '/usr/bin/rsh' fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 53 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = V (\126) Msg = "" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 54 bytes] beavis.DaytonOH.NCR.COM: >>> Cmd = V (\126) Msg = "6" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 42 bytes] beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 193 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: >>> Cmd = c (\143) Msg = "Hfievel" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 598 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Debug files->n_next= 134905856, destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: Debug sc->sc_name=80a7fe8, destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: install(src=testdir1,dest=/tmp,ddir=1,destdir=1,opts=36) start beavis.DaytonOH.NCR.COM: install -ofollow,younger testdir1 /tmp beavis.DaytonOH.NCR.COM: install: target=testdir1 src=testdir1 rname=testdir1 dest='/tmp' destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: >>> Cmd = T (\124) Msg = "44 /tmp" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 91 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 204 bytes] beavis.DaytonOH.NCR.COM: sendit(testdir1, 24) beavis.DaytonOH.NCR.COM: except(testdir1) beavis.DaytonOH.NCR.COM: update(testdir1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testdir1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 291 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testdir1 (testdir1) is 1 beavis.DaytonOH.NCR.COM: testdir1: installing beavis.DaytonOH.NCR.COM: >>> Cmd = D (\104) Msg = "44 0755 0 0 0 root other testdir1" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 81 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\003) Msg = "beavis: /tmp/testdir1: mkdir" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 54 bytes] beavis.DaytonOH.NCR.COM: beavis: /tmp/testdir1: mkdir fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 42 bytes] beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 308 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testfile1, 24) beavis.DaytonOH.NCR.COM: except(testdir1/testfile1) beavis.DaytonOH.NCR.COM: update(testfile1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testfile1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 329 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testfile1 (testdir1/testfile1) is 1 beavis.DaytonOH.NCR.COM: testdir1/testfile1: installing beavis.DaytonOH.NCR.COM: >>> Cmd = R (\122) Msg = "44 0644 0 763141933 763141933 root other testfile1" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 298 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Send file 'testfile1' 0 bytes beavis.DaytonOH.NCR.COM: Send file 'complete' testfile1. beavis.DaytonOH.NCR.COM: >>> Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 668 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=testfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=testfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: sendit(linkfile1, 24) beavis.DaytonOH.NCR.COM: except(testdir1/linkfile1) beavis.DaytonOH.NCR.COM: update(linkfile1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "linkfile1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status linkfile1 (testdir1/linkfile1) is 1 beavis.DaytonOH.NCR.COM: testdir1/linkfile1: installing beavis.DaytonOH.NCR.COM: sendhardlink: rname='linkfile1' pathname='testdir1/testfile1' src='testdir1' target='/tmp' beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=linkfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: sendhardlink: lname=/tmp/testfile1 beavis.DaytonOH.NCR.COM: >>> Cmd = k (\153) Msg = "44 /tmp/testfile1 linkfile1" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\001) Msg = "beavis: REMOTE ERROR: /tmp/testdir1/linkfile1: cannot link to /tmp/testfile1: No such file or directory" beavis.DaytonOH.NCR.COM: beavis: REMOTE ERROR: /tmp/testdir1/linkfile1: cannot link to /tmp/testfile1: No such file or directory beavis.DaytonOH.NCR.COM: >>> Cmd = E (\105) Msg = "" beavis.DaytonOH.NCR.COM:fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: install(src=testdir2,dest=/tmp,ddir=1,destdir=1,opts=36) start beavis.DaytonOH.NCR.COM: install -ofollow,younger testdir2 /tmp beavis.DaytonOH.NCR.COM: install: target=testdir2 src=testdir2 rname=testdir2 dest='/tmp' destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: >>> Cmd = T (\124) Msg = "44 /tmp" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testdir2, 24) beavis.DaytonOH.NCR.COM: except(testdir2) beavis.DaytonOH.NCR.COM: update(testdir2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testdir2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testdir2 (testdir2) is 1 beavis.DaytonOH.NCR.COM: testdir2: installing beavis.DaytonOH.NCR.COM: >>> Cmd = D (\104) Msg = "44 0755 0 0 0 root other testdir2" beavis.Dafievel: reap() called fievel: waitproc() nonblocking, active children = 1... fievel: waitproc() done (activechildren = 1) fievel: reap() pid = 20356 status = 0 activechildren=1 fievel: waitproc() nonblocking, active children = 1... fievel: waitproc() done (activechildren = 1) fievel: reap() pid = -1 status = 0 activechildren=1 fievel: reap() done fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\003) Msg = "beavis: /tmp/testdir2: mkdir" beavis.DaytonOH.NCR.COM: beavis: /tmp/testdir2: mkdir beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testfile2, 24) beavis.DaytonOH.NCR.COM: except(testdir2/testfile2) beavis.DaytonOH.NCR.COM: update(testfile2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testfile2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testfile2 (testdir2/testfile2) is 1 beavis.DaytonOH.NCR.COM: testdir2/testfile2: installing beavis.DaytonOH.NCR.COM: >>> Cmd = R (\122) Msg = "44 0644 0 763141982 763141982 root other testfile2" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Send file 'testfile2' 0 bytes beavis.DaytonOH.NCR.COM: Send ffievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ile 'complete' testfile2. beavis.DaytonOH.NCR.COM: >>> Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=testfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=testfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: sendit(linkfile2, 24) beavis.DaytonOH.NCR.COM: except(testdir2/linkfile2) beavis.DaytonOH.NCR.COM: update(linkfile2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "linkfile2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status linkfile2 (testdir2/linkfile2) is 1 beavis.DaytonOH.NCR.COM: testdir2/linkfile2: installing beavis.DaytonOH.NCR.COM: sendhardlink: rname='linkffievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ile2' pathname='testdir2/testfile2' src='testdir2' target='/tmp' beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=linkfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: sendhardlink: lname=/tmp/testfile2 beavis.DaytonOH.NCR.COM: >>> Cmd = k (\153) Msg = "44 /tmp/testfile2 linkfile2" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\001) Msg = "beavis: REMOTE ERROR: /tmp/testdir2/linkfile2: cannot link to /tmp/testfile2: No such file or directory" beavis.DaytonOH.NCR.COM: beavis: REMOTE ERROR: /tmp/testdir2/linkfile2: cannot link to /tmp/testfile2: No such file or directory beavis.DaytonOH.NCR.COM: >>> Cmd = E (\105) Msg = "" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: updating of beavis.DaytonOH.NCR.COM finished beavis.DaytonOH.NCR.COM: closeconn() called beavis.Daytofievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 41 bytes] nOH.NCR.COM: >>> Cmd =  (\002) Msg = "" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 4 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: childscan() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 4 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: removechild(beavis.DaytonOH.NCR.COM, 20356, 9) start fievel: removechild() end fievel: childscan() end From tmoore@fievel.DaytonOH.NCR.COM Tue Mar 8 09:35:23 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05723; Tue, 8 Mar 94 09:35:23 PST Message-Id: <9403081735.AA05723@usc.edu> Subject: Bad address To: rdist-dev@usc.edu Date: Tue, 8 Mar 1994 12:35:20 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 383 To anyone who may be trying to reply to my message, please be advised that we have a bit of a name clash here. The address Tom.Moore@DaytonOH.NCR.COM will currently bounce as ambiguous. This will be fixed shortly. In the meantime, use tmoore@fievel.DaytonOH.NCR.COM or Tom.J.Moore@DaytonOH.NCR.COM. Sorry for any inconvience. -- Tom Moore, Electronic Information Interchange From Anthony.Datri@amd.com Tue Mar 8 09:35:32 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05731; Tue, 8 Mar 94 09:35:32 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA01949 (5.67a/IDA-1.5+AMD for ); Tue, 8 Mar 1994 09:35:17 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA24830 (5.67a/IDA-1.5+AMD); Tue, 8 Mar 1994 09:35:15 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA23403; Tue, 8 Mar 94 11:34:06 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA25832; Tue, 8 Mar 94 11:35:31 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 8 Mar 1994 11:35:30 -0600 (CST) Message-Id: Date: Tue, 8 Mar 1994 11:35:30 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu (Rdist Development Group), "Tom Moore" Subject: Re: Still having problems with linked files In-Reply-To: <9403081636.AA03637@usc.edu> References: <9403081636.AA03637@usc.edu> I have the same problem with beta2 -- and have had it with older versions. Another problem: foo: (/path/dir/somefile) -> (host) install /etc; rdist (I haven't tried beta3) will forcibly install somefile *as a directory* on top of /etc. The workaround is to include at least two files in the package: foo: (/path/dir/{some,other}file) -> (host) install /etc; This forces rdist to put somefile and otherfile *under* /etc. >--=8======================================================================--- From dbeusee@us.oracle.com Tue Mar 8 10:17:09 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07338; Tue, 8 Mar 94 10:17:09 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id KAA10033; Tue, 8 Mar 1994 10:17:06 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id KAA21527; Tue, 8 Mar 1994 10:14:38 -0800 Message-Id: <199403081814.KAA21527@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 10:14:38 -0800 From: Don Beusee To: rdist-dev@usc.edu, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Still having problems with linked files I'm checking into it now. I've added your test case to my test suit and I will come up with a patch for this one and run it through my new test suit. I have not come across this particular case myself, so it was not tested prior to now. Regards, Don. From tmoore@fievel.DaytonOH.NCR.COM Tue Mar 8 09:05:36 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id JAA20836 for ; Tue, 8 Mar 1994 09:05:34 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id JAA03448; Tue, 8 Mar 1994 09:07:40 -0800 Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03637; Tue, 8 Mar 94 08:36:56 PST Message-Id: <9403081636.AA03637@usc.edu> Subject: Still having problems with linked files To: rdist-dev@usc.edu (Rdist Development Group) Date: Tue, 8 Mar 1994 11:36:52 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 21605 Status: R I had inquired about this previously and at that time there were a flurry of patches flying about that could effect this. Since things seem a bit more stable at this time, I decided to resurface it. I picked up the rdist-6.1beta.3.tar.gz file and compiled it on my NCR System 3000. I had hoped that the problem I was having with linked files would be fixed. No such luck. Here is my test scenario: 1. Create a directory (testdir1) containing a file (testfile1) and a hard link to it (linkfile1). 2. Create a directory (testdir2) containing a file (testfile2) and a hard link to it (linkfile2). 3. Try to update a remote host with the following Distfile. HOST = beavis.DaytonOH.NCR.COM ( testdir1 testdir2 ) -> ${HOST} install /tmp ; The directories testdir1 and testdir2 will be made. The files testfile1 and testfile2 will be installed. The installation of the files linkfile1 and linkfile2 will fail. The software is attempting to link /tmp/testfile1 to /tmp/testdir1/linkfile1 on the remote system. Can anyone enlighten me as to what the problem is? I have included the debug output below. -- Tom Moore, Electronic Information Interchange ./rdist -D -ofollow,younger -f Distfile.test2 Version 6.1beta.3 - Protocol Version 6, Release 6.1beta, Patch level 3 fievel: Current message logging config: fievel: stdout=change,info,notice,nerror,ferror,warning,verbose,all,debug fievel: file= fievel: syslog=,nerror,ferror,all fievel: notify=change,info,notice,nerror,ferror,warning,verbose,all fievel: makenl(beavis.DaytonOH.NCR.COM) fievel: lookup(HOST, 1, 80a7f94) fievel: makenl(testdir1) fievel: makenl(testdir2) fievel: makenl(${HOST}) fievel: makenl(/tmp) fievel: expand(80a7fdc, 1) start, list = ( /tmp ) fievel: makenl(null) fievel: insert((null), 80a7fa0, 80a7fc4, 80a8c98) start, files = ( testdir1 testdir2 ) fievel: expand(80a7fa0, 3) start, list = ( testdir1 testdir2 ) fievel: makenl(null) fievel: makenl(null) fievel: expand(80a7fc4, 7) start, list = ( ${HOST} ) fievel: lookup(HOST, 0, 0) fievel: makenl(null) fievel: addchild() start fievel: addchild() created 'beavis.DaytonOH.NCR.COM' pid 20356 fd 9 (active=1) fievel: spawn() Forked child 20356 for host beavis.DaytonOH.NCR.COM active = 1 fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 204 bytes] beavis.DaytonOH.NCR.COM: doarrow(80a7ff4, beavis.DaytonOH.NCR.COM, 80a8c98) start beavis.DaytonOH.NCR.COM: makeconn(beavis.DaytonOH.NCR.COM) beavis.DaytonOH.NCR.COM: updating host beavis.DaytonOH.NCR.COM fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 248 bytes] beavis.DaytonOH.NCR.COM: Created notify temp file '/tmp/rdista004y4' beavis.DaytonOH.NCR.COM: local user = root remote user = root beavis.DaytonOH.NCR.COM: Remote command = 'rdistd -S' beavis.DaytonOH.NCR.COM: Remote shell command = '/usr/bin/rsh' fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 53 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = V (\126) Msg = "" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 54 bytes] beavis.DaytonOH.NCR.COM: >>> Cmd = V (\126) Msg = "6" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 42 bytes] beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 193 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: >>> Cmd = c (\143) Msg = "Hfievel" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 598 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Debug files->n_next= 134905856, destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: Debug sc->sc_name=80a7fe8, destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: install(src=testdir1,dest=/tmp,ddir=1,destdir=1,opts=36) start beavis.DaytonOH.NCR.COM: install -ofollow,younger testdir1 /tmp beavis.DaytonOH.NCR.COM: install: target=testdir1 src=testdir1 rname=testdir1 dest='/tmp' destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: >>> Cmd = T (\124) Msg = "44 /tmp" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 91 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 204 bytes] beavis.DaytonOH.NCR.COM: sendit(testdir1, 24) beavis.DaytonOH.NCR.COM: except(testdir1) beavis.DaytonOH.NCR.COM: update(testdir1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testdir1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 291 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testdir1 (testdir1) is 1 beavis.DaytonOH.NCR.COM: testdir1: installing beavis.DaytonOH.NCR.COM: >>> Cmd = D (\104) Msg = "44 0755 0 0 0 root other testdir1" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 81 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\003) Msg = "beavis: /tmp/testdir1: mkdir" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 54 bytes] beavis.DaytonOH.NCR.COM: beavis: /tmp/testdir1: mkdir fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 42 bytes] beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 308 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testfile1, 24) beavis.DaytonOH.NCR.COM: except(testdir1/testfile1) beavis.DaytonOH.NCR.COM: update(testfile1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testfile1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 329 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testfile1 (testdir1/testfile1) is 1 beavis.DaytonOH.NCR.COM: testdir1/testfile1: installing beavis.DaytonOH.NCR.COM: >>> Cmd = R (\122) Msg = "44 0644 0 763141933 763141933 root other testfile1" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 298 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Send file 'testfile1' 0 bytes beavis.DaytonOH.NCR.COM: Send file 'complete' testfile1. beavis.DaytonOH.NCR.COM: >>> Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: response() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 0 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: waitup() select on 9 (beavis.DaytonOH.NCR.COM) fievel: waitup() Call select(), activechildren=1 fievel: waitup() select returned 1 activechildren = 1 fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 668 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=testfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=testfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: sendit(linkfile1, 24) beavis.DaytonOH.NCR.COM: except(testdir1/linkfile1) beavis.DaytonOH.NCR.COM: update(linkfile1, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "linkfile1" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status linkfile1 (testdir1/linkfile1) is 1 beavis.DaytonOH.NCR.COM: testdir1/linkfile1: installing beavis.DaytonOH.NCR.COM: sendhardlink: rname='linkfile1' pathname='testdir1/testfile1' src='testdir1' target='/tmp' beavis.DaytonOH.NCR.COM: remfilename: src=testdir1 dest=/tmp path=testdir1/testfile1 rname=linkfile1 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile1 beavis.DaytonOH.NCR.COM: sendhardlink: lname=/tmp/testfile1 beavis.DaytonOH.NCR.COM: >>> Cmd = k (\153) Msg = "44 /tmp/testfile1 linkfile1" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\001) Msg = "beavis: REMOTE ERROR: /tmp/testdir1/linkfile1: cannot link to /tmp/testfile1: No such file or directory" beavis.DaytonOH.NCR.COM: beavis: REMOTE ERROR: /tmp/testdir1/linkfile1: cannot link to /tmp/testfile1: No such file or directory beavis.DaytonOH.NCR.COM: >>> Cmd = E (\105) Msg = "" beavis.DaytonOH.NCR.COM:fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: install(src=testdir2,dest=/tmp,ddir=1,destdir=1,opts=36) start beavis.DaytonOH.NCR.COM: install -ofollow,younger testdir2 /tmp beavis.DaytonOH.NCR.COM: install: target=testdir2 src=testdir2 rname=testdir2 dest='/tmp' destdir=1, ddir=1 beavis.DaytonOH.NCR.COM: >>> Cmd = T (\124) Msg = "44 /tmp" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testdir2, 24) beavis.DaytonOH.NCR.COM: except(testdir2) beavis.DaytonOH.NCR.COM: update(testdir2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testdir2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testdir2 (testdir2) is 1 beavis.DaytonOH.NCR.COM: testdir2: installing beavis.DaytonOH.NCR.COM: >>> Cmd = D (\104) Msg = "44 0755 0 0 0 root other testdir2" beavis.Dafievel: reap() called fievel: waitproc() nonblocking, active children = 1... fievel: waitproc() done (activechildren = 1) fievel: reap() pid = 20356 status = 0 activechildren=1 fievel: waitproc() nonblocking, active children = 1... fievel: waitproc() done (activechildren = 1) fievel: reap() pid = -1 status = 0 activechildren=1 fievel: reap() done fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\003) Msg = "beavis: /tmp/testdir2: mkdir" beavis.DaytonOH.NCR.COM: beavis: /tmp/testdir2: mkdir beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: sendit(testfile2, 24) beavis.DaytonOH.NCR.COM: except(testdir2/testfile2) beavis.DaytonOH.NCR.COM: update(testfile2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "testfile2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status testfile2 (testdir2/testfile2) is 1 beavis.DaytonOH.NCR.COM: testdir2/testfile2: installing beavis.DaytonOH.NCR.COM: >>> Cmd = R (\122) Msg = "44 0644 0 763141982 763141982 root other testfile2" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: Send file 'testfile2' 0 bytes beavis.DaytonOH.NCR.COM: Send ffievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ile 'complete' testfile2. beavis.DaytonOH.NCR.COM: >>> Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=testfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=testfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: sendit(linkfile2, 24) beavis.DaytonOH.NCR.COM: except(testdir2/linkfile2) beavis.DaytonOH.NCR.COM: update(linkfile2, 24, 805f154) beavis.DaytonOH.NCR.COM: >>> Cmd = Q (\121) Msg = "linkfile2" beavis.DaytonOH.NCR.COM: <<< Cmd = N (\116) Msg = "" beavis.DaytonOH.NCR.COM: update status linkfile2 (testdir2/linkfile2) is 1 beavis.DaytonOH.NCR.COM: testdir2/linkfile2: installing beavis.DaytonOH.NCR.COM: sendhardlink: rname='linkffievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 1024 bytes] ile2' pathname='testdir2/testfile2' src='testdir2' target='/tmp' beavis.DaytonOH.NCR.COM: remfilename: src=testdir2 dest=/tmp path=testdir2/testfile2 rname=linkfile2 destdir=1 beavis.DaytonOH.NCR.COM: remfilename: remote filename=/tmp/testfile2 beavis.DaytonOH.NCR.COM: sendhardlink: lname=/tmp/testfile2 beavis.DaytonOH.NCR.COM: >>> Cmd = k (\153) Msg = "44 /tmp/testfile2 linkfile2" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\001) Msg = "beavis: REMOTE ERROR: /tmp/testdir2/linkfile2: cannot link to /tmp/testfile2: No such file or directory" beavis.DaytonOH.NCR.COM: beavis: REMOTE ERROR: /tmp/testdir2/linkfile2: cannot link to /tmp/testfile2: No such file or directory beavis.DaytonOH.NCR.COM: >>> Cmd = E (\105) Msg = "" beavis.DaytonOH.NCR.COM: response() start beavis.DaytonOH.NCR.COM: <<< Cmd =  (\005) Msg = "" beavis.DaytonOH.NCR.COM: received ACK beavis.DaytonOH.NCR.COM: updating of beavis.DaytonOH.NCR.COM finished beavis.DaytonOH.NCR.COM: closeconn() called beavis.Daytofievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) got 41 bytes] nOH.NCR.COM: >>> Cmd =  (\002) Msg = "" fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) write done] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 4 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: waitup() end fievel: Waiting for 1 children to finish. fievel: waitup() start fievel: childscan() start fievel: [readchild(beavis.DaytonOH.NCR.COM, 20356, 9) start] fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) done: amt = 0 errno = 4 fievel: readchild(beavis.DaytonOH.NCR.COM, 20356, 9) at EOF fievel: removechild(beavis.DaytonOH.NCR.COM, 20356, 9) start fievel: removechild() end fievel: childscan() end From dbeusee@us.oracle.com Tue Mar 8 11:20:16 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10111; Tue, 8 Mar 94 11:20:16 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id LAA15924; Tue, 8 Mar 1994 11:18:55 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id LAA22292; Tue, 8 Mar 1994 11:16:33 -0800 Message-Id: <199403081916.LAA22292@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 11:16:33 -0800 From: Don Beusee To: aad@lovecraft.amd.com, rdist-dev@usc.edu, tmoore@fievel.daytonoh.ncr.com Subject: Re: Still having problems with linked files This is not the same problem. Its quite a different one, and in fact not a bug, but a feature, since rdist has no way to know that /etc SHOULD be a file or directory. It will assume you want to replace it with the file you have given it. The correct approach is to do: foo: (/path/dir/somefile) -> (host) install /etc/.; The /. after /etc tells rdist that /etc should be a DIRECTORY and it will do the correct thing in Beta3, or a patched Beta2. This is the reliable method. My test case already included file -> host install /dir/.; and Beta3 passed that wth flying colors. Regards, Don. From Anthony.Datri@amd.com Tue Mar 8 10:12:56 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id KAA21517 for ; Tue, 8 Mar 1994 10:12:55 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id KAA09922; Tue, 8 Mar 1994 10:15:08 -0800 Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05731; Tue, 8 Mar 94 09:35:32 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA01949 (5.67a/IDA-1.5+AMD for ); Tue, 8 Mar 1994 09:35:17 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA24830 (5.67a/IDA-1.5+AMD); Tue, 8 Mar 1994 09:35:15 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA23403; Tue, 8 Mar 94 11:34:06 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA25832; Tue, 8 Mar 94 11:35:31 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 8 Mar 1994 11:35:30 -0600 (CST) Message-Id: Date: Tue, 8 Mar 1994 11:35:30 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu (Rdist Development Group), "Tom Moore" Subject: Re: Still having problems with linked files In-Reply-To: <9403081636.AA03637@usc.edu> References: <9403081636.AA03637@usc.edu> Status: R I have the same problem with beta2 -- and have had it with older versions. Another problem: foo: (/path/dir/somefile) -> (host) install /etc; rdist (I haven't tried beta3) will forcibly install somefile *as a directory* on top of /etc. The workaround is to include at least two files in the package: foo: (/path/dir/{some,other}file) -> (host) install /etc; This forces rdist to put somefile and otherfile *under* /etc. >--=8======================================================================--- From Anthony.Datri@amd.com Tue Mar 8 12:19:38 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12225; Tue, 8 Mar 94 12:19:38 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA12799 (5.67a/IDA-1.5+AMD for ); Tue, 8 Mar 1994 12:19:14 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA00158 (5.67a/IDA-1.5+AMD); Tue, 8 Mar 1994 12:19:13 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA04420; Tue, 8 Mar 94 14:18:02 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA26019; Tue, 8 Mar 94 14:19:28 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 8 Mar 1994 14:19:27 -0600 (CST) Message-Id: Date: Tue, 8 Mar 1994 14:19:27 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, tmoore@fievel.daytonoh.ncr.com, Don Beusee Subject: Re: Still having problems with linked files In-Reply-To: <199403081916.LAA22292@dbeusee.us.oracle.com> References: <199403081916.LAA22292@dbeusee.us.oracle.com> >The /. after /etc tells rdist that /etc should be a DIRECTORY What I've seen is that rdist will install the file *as* a directory -- which, of course, doesn't work very well. >--=8======================================================================--- From dbeusee@us.oracle.com Tue Mar 8 12:23:10 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12427; Tue, 8 Mar 94 12:23:10 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id MAA21370; Tue, 8 Mar 1994 12:22:36 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id MAA23186; Tue, 8 Mar 1994 12:20:19 -0800 Message-Id: <199403082020.MAA23186@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 12:20:19 -0800 From: Don Beusee To: aad@lovecraft.amd.com, rdist-dev@usc.edu, tmoore@fievel.daytonoh.ncr.com Subject: Re: Still having problems with linked files No, it does not. My patches (included in Beta3) do the right thing. It installs the file IN the directory. Regards, Don. From Anthony.Datri@amd.com Tue Mar 8 12:17:11 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id MAA23102 for ; Tue, 8 Mar 1994 12:17:10 -0800 Received: from amdext.amd.com by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id MAA21220; Tue, 8 Mar 1994 12:19:25 -0800 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA12799 (5.67a/IDA-1.5+AMD for ); Tue, 8 Mar 1994 12:19:14 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA00158 (5.67a/IDA-1.5+AMD); Tue, 8 Mar 1994 12:19:13 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA04420; Tue, 8 Mar 94 14:18:02 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA26019; Tue, 8 Mar 94 14:19:28 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 8 Mar 1994 14:19:27 -0600 (CST) Message-Id: Date: Tue, 8 Mar 1994 14:19:27 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, tmoore@fievel.daytonoh.ncr.com, Don Beusee Subject: Re: Still having problems with linked files In-Reply-To: <199403081916.LAA22292@dbeusee.us.oracle.com> References: <199403081916.LAA22292@dbeusee.us.oracle.com> Status: R >The /. after /etc tells rdist that /etc should be a DIRECTORY What I've seen is that rdist will install the file *as* a directory -- which, of course, doesn't work very well. >--=8======================================================================--- From rouilj@cs.umb.edu Tue Mar 8 13:01:25 1994 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13891; Tue, 8 Mar 94 13:01:25 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA20574 (5.65c/IDA-1.4.4 for ); Tue, 8 Mar 1994 16:01:08 -0500 Message-Id: <199403082101.AA20574@cs.umb.edu> To: rdist-dev@usc.edu Subject: Re: Still having problems with linked files In-Reply-To: Your message of "Tue, 08 Mar 1994 14:19:27 CST." Date: Tue, 08 Mar 1994 16:01:07 -0500 From: "John P. Rouillard" In message , Anthony D'atri writes: > >The /. after /etc tells rdist that /etc should be a DIRECTORY Way back when 6.0 was in beta, I argued that a special option should be required at allow a file to overwrite a directory. Say yes_really_kill_the_direcory_because_I_want_to_shoot_myself_in_the_foot or some such option. If I had a nickle for every time I almost saw a new rdist user do: /config/passwd -> machine install /etc ; I'd be rich. Compare the behavior of rdist to the following: rcp /config/passwd machine:/etc mv /config/passwd /etc cp /config/passwd /etc None of these will overwrite the destination directory. In classic rdist, it gave an error message if you tried to overwrite a directory with a file. I really really think the new rdist blew it when it broke the install semantics like this. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From tmoore@fievel.DaytonOH.NCR.COM Tue Mar 8 13:20:32 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14646; Tue, 8 Mar 94 13:20:32 PST Message-Id: <9403082120.AA14646@usc.edu> Subject: Adding host authentication to rdist To: rdist-dev@usc.edu (Rdist Development Group) Date: Tue, 8 Mar 1994 16:20:27 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2818 There is a need here to provide a more reliable method of authenticating what hosts are communicating with rdist than is provided by remote command execution. The consensus here is that this can be spoofed and should not be trusted. We solved this by adding a challenge/response authentication to the rdist protocol at startup. A password file is maintained at each host listing the hosts it talks to: FQ_host_name password When the connection is established, the following exchange takes place: remote sends name as (beavis.daytonoh.ncr.com) <<< Cmd = H (\110) Msg = "beavis.daytonoh.ncr.com" local sends hostname as (fievel.DaytonOH.NCR.COM) >>> Cmd = H (\110) Msg = "fievel.DaytonOH.NCR.COM" remote sends ACK <<< Cmd =  (\005) Msg = "" This establishes the full hostname for both hosts. Then the challenge and response part using the hostname for password lookup and a date string as the challenge. (Notice that my remote machine has a strange idea of what time it is but it does not matter.) remote sends challenge (Tue Mar 8 16:01:20 1994) <<< Cmd = A (\101) Msg = "CTue Mar 8 16:01:20 1994" local responds with (eQ1gNU+6IKRNoSmaaCJZr4Gf2BZh2HkU) >>> Cmd = A (\101) Msg = "ReQ1gNU+6IKRNoSmaaCJZr4Gf2BZh2HkU" remote sends ACK (He knows we are who we say we are) <<< Cmd =  (\005) Msg = "" local sends challenge (Tue Mar 8 15:43:10 1994) >>> Cmd = A (\101) Msg = "CTue Mar 8 15:43:10 1994" remote responds with (eQ1gNU+6IKSuNoo0LgJjfv6Uu4jg00U3) <<< Cmd = A (\101) Msg = "ReQ1gNU+6IKSuNoo0LgJjfv6Uu4jg00U3" local sends ACK (We know he is who he says he is) >>> Cmd =  (\005) Msg = "" authentication OK Then the exchange of version strings as before. This actually ran quite well when the program ran as root as I started both client and server as root to read the rdist password file and validate hosts and then reverted back the user ID. This was only necessary since the rdist password file was owned and readable only by root. With the change in operation to not use root, it would seem better to allow each user to have their own rdist password file like a .rhosts file. The authentication could then be an option that could be used as desired. I have all of this running in the 6.1.b3 version now if there is an interest in rolling it back into the main code. Comments? -- * "If we couldn't laugh at things that don't make sense, we couldn't react * * to a lot of life" --- Hobbes * * * * Tom Moore AT&T Global Information Solutions (513) 445-1373 * * Technology Consultant 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network System Solutions Dayton, OH 45479 Tom.Moore@DaytonOH.NCR.COM * From Anthony.Datri@amd.com Tue Mar 8 13:58:38 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17033; Tue, 8 Mar 94 13:58:38 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA19762 (5.67a/IDA-1.5+AMD for ); Tue, 8 Mar 1994 13:58:34 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA03186 (5.67a/IDA-1.5+AMD); Tue, 8 Mar 1994 13:58:33 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA13362; Tue, 8 Mar 94 15:57:21 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA26557; Tue, 8 Mar 94 15:58:47 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 8 Mar 1994 15:58:47 -0600 (CST) Message-Id: <0hTDIL6XhG4BJVXLAY@lovecraft.amd.com> Date: Tue, 8 Mar 1994 15:58:47 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, "John P. Rouillard" Subject: Re: Still having problems with linked files In-Reply-To: <199403082101.AA20574@cs.umb.edu> References: <199403082101.AA20574@cs.umb.edu> > I really really think the new rdist blew it when it broke >the install semantics like this. I agree. I cannot imagine why I might *ever* want to install a plain file as a directory. >--=8======================================================================--- From dbeusee@us.oracle.com Tue Mar 8 14:17:02 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18310; Tue, 8 Mar 94 14:17:02 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id OAA00658; Tue, 8 Mar 1994 14:16:59 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA24239; Tue, 8 Mar 1994 14:14:36 -0800 Message-Id: <199403082214.OAA24239@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 14:14:36 -0800 From: Don Beusee To: rdist-dev@usc.edu, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Mike just got rdist to be a non-setuid program. I think it would be better to use a front end wrapper to rsh and have rdist call that. This will allow you to have a more secure rsh as well. Be careful doing any authentication based on dates/times. What happens when you try to connect to a host in a different timezone? Its not real clear to me how this works (exactly what the date does). Maybe you could show me a handshake that fails and highlight the difference. Regards, Don. From tmoore@fievel.DaytonOH.NCR.COM Tue Mar 8 13:43:17 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id NAA23914 for ; Tue, 8 Mar 1994 13:43:16 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id NAA27998; Tue, 8 Mar 1994 13:45:30 -0800 Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14646; Tue, 8 Mar 94 13:20:32 PST Message-Id: <9403082120.AA14646@usc.edu> Subject: Adding host authentication to rdist To: rdist-dev@usc.edu (Rdist Development Group) Date: Tue, 8 Mar 1994 16:20:27 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2818 Status: R There is a need here to provide a more reliable method of authenticating what hosts are communicating with rdist than is provided by remote command execution. The consensus here is that this can be spoofed and should not be trusted. We solved this by adding a challenge/response authentication to the rdist protocol at startup. A password file is maintained at each host listing the hosts it talks to: FQ_host_name password When the connection is established, the following exchange takes place: remote sends name as (beavis.daytonoh.ncr.com) <<< Cmd = H (\110) Msg = "beavis.daytonoh.ncr.com" local sends hostname as (fievel.DaytonOH.NCR.COM) >>> Cmd = H (\110) Msg = "fievel.DaytonOH.NCR.COM" remote sends ACK <<< Cmd =  (\005) Msg = "" This establishes the full hostname for both hosts. Then the challenge and response part using the hostname for password lookup and a date string as the challenge. (Notice that my remote machine has a strange idea of what time it is but it does not matter.) remote sends challenge (Tue Mar 8 16:01:20 1994) <<< Cmd = A (\101) Msg = "CTue Mar 8 16:01:20 1994" local responds with (eQ1gNU+6IKRNoSmaaCJZr4Gf2BZh2HkU) >>> Cmd = A (\101) Msg = "ReQ1gNU+6IKRNoSmaaCJZr4Gf2BZh2HkU" remote sends ACK (He knows we are who we say we are) <<< Cmd =  (\005) Msg = "" local sends challenge (Tue Mar 8 15:43:10 1994) >>> Cmd = A (\101) Msg = "CTue Mar 8 15:43:10 1994" remote responds with (eQ1gNU+6IKSuNoo0LgJjfv6Uu4jg00U3) <<< Cmd = A (\101) Msg = "ReQ1gNU+6IKSuNoo0LgJjfv6Uu4jg00U3" local sends ACK (We know he is who he says he is) >>> Cmd =  (\005) Msg = "" authentication OK Then the exchange of version strings as before. This actually ran quite well when the program ran as root as I started both client and server as root to read the rdist password file and validate hosts and then reverted back the user ID. This was only necessary since the rdist password file was owned and readable only by root. With the change in operation to not use root, it would seem better to allow each user to have their own rdist password file like a .rhosts file. The authentication could then be an option that could be used as desired. I have all of this running in the 6.1.b3 version now if there is an interest in rolling it back into the main code. Comments? -- * "If we couldn't laugh at things that don't make sense, we couldn't react * * to a lot of life" --- Hobbes * * * * Tom Moore AT&T Global Information Solutions (513) 445-1373 * * Technology Consultant 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network System Solutions Dayton, OH 45479 Tom.Moore@DaytonOH.NCR.COM * From dbeusee@us.oracle.com Tue Mar 8 14:50:46 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20267; Tue, 8 Mar 94 14:50:46 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id OAA03800; Tue, 8 Mar 1994 14:50:40 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA24617; Tue, 8 Mar 1994 14:48:22 -0800 Message-Id: <199403082248.OAA24617@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 14:48:22 -0800 From: Don Beusee To: rdist-dev@usc.edu, rouilj@terminus.cs.umb.edu Subject: Re: Still having problems with linked files As I indicated, rdist will NOT actually blow away the directory: dbeusee: REMOTE ERROR: /tmp/rdista24462 -> /tmp/rdist: rename failed: Is a directory The only unfortunate thing is that after that error, rdist looses protocol syncronization: dbeusee: LOCAL ERROR: update: unexpected response to query '' dbeusee: Y2 763154689 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response to query '' dbeusee: Y7 763154690 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response to query '' dbeusee: Y7 763154690 644 root daemon dbeusee: LOCAL ERROR: update: unexpected response to query '' dbeusee: Y3 763154689 644 root daemon Compare v4 with v6: rdist4 -c z dbeusee:/tmp/rdist updating host dbeusee updating: z rdist: dbeusee:/tmp/rdist: Is a directory rdist6 -c z dbeusee:/tmp/rdist dbeusee: updating host dbeusee dbeusee: z: updating dbeusee: REMOTE ERROR: /tmp/rdista24615 -> /tmp/rdist: rename failed: Is a directory dbeusee: updating of dbeusee finished Regards, Don. From rouilj@cs.umb.edu Tue Mar 8 13:41:28 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id NAA23906 for ; Tue, 8 Mar 1994 13:41:28 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id NAA27881; Tue, 8 Mar 1994 13:43:40 -0800 Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13891; Tue, 8 Mar 94 13:01:25 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA20574 (5.65c/IDA-1.4.4 for ); Tue, 8 Mar 1994 16:01:08 -0500 Message-Id: <199403082101.AA20574@cs.umb.edu> To: rdist-dev@usc.edu Subject: Re: Still having problems with linked files In-Reply-To: Your message of "Tue, 08 Mar 1994 14:19:27 CST." Date: Tue, 08 Mar 1994 16:01:07 -0500 From: "John P. Rouillard" Status: R In message , Anthony D'atri writes: > >The /. after /etc tells rdist that /etc should be a DIRECTORY Way back when 6.0 was in beta, I argued that a special option should be required at allow a file to overwrite a directory. Say yes_really_kill_the_direcory_because_I_want_to_shoot_myself_in_the_foot or some such option. If I had a nickle for every time I almost saw a new rdist user do: /config/passwd -> machine install /etc ; I'd be rich. Compare the behavior of rdist to the following: rcp /config/passwd machine:/etc mv /config/passwd /etc cp /config/passwd /etc None of these will overwrite the destination directory. In classic rdist, it gave an error message if you tried to overwrite a directory with a file. I really really think the new rdist blew it when it broke the install semantics like this. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From raeburn@cygnus.com Tue Mar 8 16:17:14 1994 Return-Path: Received: from relay2.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24048; Tue, 8 Mar 94 16:17:14 PST Received: from cygnus.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwgkf15964; Tue, 8 Mar 94 19:16:58 -0500 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA28298; Tue, 8 Mar 94 16:16:53 PST From: raeburn@cygnus.com (Ken Raeburn) Received: from cambridge.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA19206; Tue, 8 Mar 94 19:16:51 EST Date: Tue, 8 Mar 94 19:16:50 EST Message-Id: <9403090016.AA19206@tweedledumb.cygnus.com> Received: by cambridge.cygnus.com (4.1/SMI-4.1) id AA03574; Tue, 8 Mar 94 19:16:30 EST To: rdist-dev@usc.edu In-Reply-To: "Tom Moore"'s message of Tue, 8 Mar 1994 16:20:27 -0500 (EST) <9403082120.AA14646@usc.edu> Subject: Re: Adding host authentication to rdist Date: Tue, 8 Mar 1994 16:20:27 -0500 (EST) From: "Tom Moore" There is a need here to provide a more reliable method of authenticating what hosts are communicating with rdist than is provided by remote command execution. The consensus here is that this can be spoofed and should not be trusted. We solved this by adding a challenge/response authentication to the rdist protocol at startup. A password file is maintained at each host listing the hosts it talks to: It'll work okay for installations with small numbers of machines, but at a site where there are lots of machines, you wind up with lots of passwords in each user's rdist password file, and you need a distribution mechanism for those rdist password files. Also, you don't want those rdist password files read over NFS unless you trust every machine on your local network. Kerberos addresses some of these issues. As long as the machine you rdist to has had Kerberos services installed by an administrator, and each user (or, for automated rdist jobs, the machine running rdist) is registered with Kerberos (that's n_users + n_hosts tasks, not n_users * n_hosts, to make all combinations work), it should be safe to use Kerberos rsh. It does require a bit of centralized administration, though. Actually, Kerberos rsh only authenticates in one direction; it's assumed that the server won't be spoofed. Not terribly wise, but spoofing the client side is probably a far more common (and interesting) attack. (Consider that updating a file on a host currently means sending it over the network in the clear anyways...) When an encrypted rsh gets implemented, the mutual-authentication code will have to be there. Alternatively, the Kerberos version of rcmd could be integrated into rdist directly, and the mutual-authentication code turned on. Ken From tmoore@fievel.daytonoh.NCR.COM Tue Mar 8 19:27:05 1994 Return-Path: Received: from ncrhub1.NCR.COM (h192-127-251-3.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00617; Tue, 8 Mar 94 19:27:05 PST Received: from ncrhub4 by ncrhub1.NCR.COM id aa15133; 8 Mar 94 17:55 EST Received: by ncrhub4.NCR.COM; 8 Mar 94 17:54:59 EST Received: by dayhub.DaytonOH.NCR.COM; 8 Mar 94 17:54:34 EST Subject: Re: Adding host authentication to rdist To: Don Beusee Date: Tue, 8 Mar 1994 17:37:19 -0500 (EST) From: Tom Moore Cc: rdist-dev@usc.edu In-Reply-To: <199403082214.OAA24239@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 02:14:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1351 Message-Id: <9403081755.aa15133@ncrhub1.NCR.COM> Don Beusee writes: > > Mike just got rdist to be a non-setuid program. I think it would be better > to use a front end wrapper to rsh and have rdist call that. This will allow > you to have a more secure rsh as well. I don't believe that rdist needs to be setuid rather I just need to change where to look for the rdist password file to allow each user (even root) to have one. I used one file before since I was only worried about making updates as root and it was already running as root. > Be careful doing any authentication based on dates/times. What happens when > you try to connect to a host in a different timezone? Its not real clear to > me how this works (exactly what the date does). Maybe you could show me a > handshake that fails and highlight the difference. The time used in the handshake is immaterial just as long as the challenge string is constantly changing to prevent replay. The method is quite simple. 1. I pick some time string and encrypt it. 2. I ask the remote to encrypt it also. 3. I compare the results. The remote does steps 1-3 for itself to authenticate the local machine. I passed this by Bill Cheswick at Bell Labs and it should be quite immune to spoofing. He suggested that I might possible use a millisecond or microsecond time string. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Tue Mar 8 20:03:51 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02070; Tue, 8 Mar 94 20:03:51 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id UAA25378; Tue, 8 Mar 1994 20:01:20 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id TAA28519; Tue, 8 Mar 1994 19:59:02 -0800 Message-Id: <199403090359.TAA28519@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 19:59:02 -0800 From: Don Beusee To: tmoore@fievel.daytonoh.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu It seems to me someone can write an easy program to pretend to be rdist or whatever s/w is doing the authentication handshake. Any program can encrypt date and pass it to the other end. If someone sniffs the net they can easily spot the pattern and write a simple program to imitate it, unless I am missing something. From tmoore@fievel.daytonoh.NCR.COM Tue Mar 8 19:24:33 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id TAA28083 for ; Tue, 8 Mar 1994 19:24:32 -0800 Received: from ncrhub1.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id TAA23606; Tue, 8 Mar 1994 19:26:47 -0800 Received: from ncrhub4 by ncrhub1.NCR.COM id aa15133; 8 Mar 94 17:55 EST Received: by ncrhub4.NCR.COM; 8 Mar 94 17:54:59 EST Received: by dayhub.DaytonOH.NCR.COM; 8 Mar 94 17:54:34 EST Subject: Re: Adding host authentication to rdist To: Don Beusee Date: Tue, 8 Mar 1994 17:37:19 -0500 (EST) From: Tom Moore Cc: rdist-dev@usc.edu In-Reply-To: <199403082214.OAA24239@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 02:14:36 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1351 Message-ID: <9403081755.aa15133@ncrhub1.NCR.COM> Status: R Don Beusee writes: > > Mike just got rdist to be a non-setuid program. I think it would be better > to use a front end wrapper to rsh and have rdist call that. This will allow > you to have a more secure rsh as well. I don't believe that rdist needs to be setuid rather I just need to change where to look for the rdist password file to allow each user (even root) to have one. I used one file before since I was only worried about making updates as root and it was already running as root. > Be careful doing any authentication based on dates/times. What happens when > you try to connect to a host in a different timezone? Its not real clear to > me how this works (exactly what the date does). Maybe you could show me a > handshake that fails and highlight the difference. The time used in the handshake is immaterial just as long as the challenge string is constantly changing to prevent replay. The method is quite simple. 1. I pick some time string and encrypt it. 2. I ask the remote to encrypt it also. 3. I compare the results. The remote does steps 1-3 for itself to authenticate the local machine. I passed this by Bill Cheswick at Bell Labs and it should be quite immune to spoofing. He suggested that I might possible use a millisecond or microsecond time string. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Tue Mar 8 20:07:56 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02179; Tue, 8 Mar 94 20:07:56 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id UAA25784; Tue, 8 Mar 1994 20:05:25 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id UAA28613; Tue, 8 Mar 1994 20:03:07 -0800 Message-Id: <199403090403.UAA28613@dbeusee.us.oracle.com> Date: Tue, 8 Mar 1994 20:03:07 -0800 From: Don Beusee To: tmoore@fievel.daytonoh.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu Is the password in your file plain text or encrypted? From tmoore@fievel.daytonoh.NCR.COM Tue Mar 8 19:45:24 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id TAA28383 for ; Tue, 8 Mar 1994 19:45:24 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id TAA24787; Tue, 8 Mar 1994 19:47:38 -0800 Received: from ncrhub1.NCR.COM (h192-127-251-3.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00617; Tue, 8 Mar 94 19:27:05 PST Received: from ncrhub4 by ncrhub1.NCR.COM id aa15133; 8 Mar 94 17:55 EST Received: by ncrhub4.NCR.COM; 8 Mar 94 17:54:59 EST Received: by dayhub.DaytonOH.NCR.COM; 8 Mar 94 17:54:34 EST Subject: Re: Adding host authentication to rdist To: Don Beusee Date: Tue, 8 Mar 1994 17:37:19 -0500 (EST) From: Tom Moore Cc: rdist-dev@usc.edu In-Reply-To: <199403082214.OAA24239@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 02:14:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1351 Message-Id: <9403081755.aa15133@ncrhub1.NCR.COM> Status: R Don Beusee writes: > > Mike just got rdist to be a non-setuid program. I think it would be better > to use a front end wrapper to rsh and have rdist call that. This will allow > you to have a more secure rsh as well. I don't believe that rdist needs to be setuid rather I just need to change where to look for the rdist password file to allow each user (even root) to have one. I used one file before since I was only worried about making updates as root and it was already running as root. > Be careful doing any authentication based on dates/times. What happens when > you try to connect to a host in a different timezone? Its not real clear to > me how this works (exactly what the date does). Maybe you could show me a > handshake that fails and highlight the difference. The time used in the handshake is immaterial just as long as the challenge string is constantly changing to prevent replay. The method is quite simple. 1. I pick some time string and encrypt it. 2. I ask the remote to encrypt it also. 3. I compare the results. The remote does steps 1-3 for itself to authenticate the local machine. I passed this by Bill Cheswick at Bell Labs and it should be quite immune to spoofing. He suggested that I might possible use a millisecond or microsecond time string. -- Tom Moore, Electronic Information Interchange From rsalz@osf.org Wed Mar 9 05:08:15 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22459; Wed, 9 Mar 94 05:08:15 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA05443; Wed, 9 Mar 94 08:08:12 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA17058; Wed, 9 Mar 94 08:07:15 -0500 Date: Wed, 9 Mar 94 08:07:15 -0500 From: rsalz@osf.org Message-Id: <9403091307.AA17058@sulphur.osf.org> To: tmoore@fievel.DaytonOH.NCR.COM, rdist-dev@usc.edu (Rdist Development Group) Subject: Re: Adding host authentication to rdist Sending cleartext username/passwords over the wire is NOT the way to go about doing anything. Leverage off what you currently have: for rdist, which wants remote execution, use rsh. If you are concerned about the security of this, then get something like a Kerberized rsh. /r$ From rsalz@osf.org Wed Mar 9 05:30:44 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22891; Wed, 9 Mar 94 05:30:44 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA08766; Wed, 9 Mar 94 08:30:43 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA17149; Wed, 9 Mar 94 08:29:45 -0500 Date: Wed, 9 Mar 94 08:29:45 -0500 From: rsalz@osf.org Message-Id: <9403091329.AA17149@sulphur.osf.org> To: tmoore@fievel.DaytonOH.NCR.COM, rdist-dev@usc.edu (Rdist Development Group) Subject: Re: Adding host authentication to rdist I forgot to add: Look at GSSAPI. The current beta Kerberos implementation from MIT includes a GSSAPI implementation done by OpenVision. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 06:36:12 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24422; Wed, 9 Mar 94 06:36:12 PST Message-Id: <9403091436.AA24422@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Wed, 9 Mar 1994 09:36:08 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403090403.UAA28613@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 08:03:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 221 Don Beusee writes: > > Is the password in your file plain text or encrypted? > The passwords in the file are plain text but the file is only readable by the owner. -- Tom Moore, Electronic Information Interchange From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 07:01:42 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24964; Wed, 9 Mar 94 07:01:42 PST Message-Id: <9403091501.AA24964@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Wed, 9 Mar 1994 09:41:12 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403090359.TAA28519@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 07:59:02 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3413 Don Beusee writes: > > It seems to me someone can write an easy program to pretend to be rdist or > whatever s/w is doing the authentication handshake. Any program can encrypt > date and pass it to the other end. If someone sniffs the net they can easily > spot the pattern and write a simple program to imitate it, unless I am missing > something. It all depends on what password you encrypt it with. The use of the date string simply provides a changing srtring to encrypt otherwise it could be easily spoofed by capture/playback. An ascii representation of a multidigit number would do quite well also. The key is that both hosts use a local copy of the same password to encrypt the challenge string. If they both get the same answer, all is well. The password never transits the network. > > >From tmoore@fievel.daytonoh.NCR.COM Tue Mar 8 19:24:33 1994 > Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP > id TAA28083 for ; Tue, 8 Mar 1994 19:24:32 -0800 > Received: from ncrhub1.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) > id TAA23606; Tue, 8 Mar 1994 19:26:47 -0800 > Received: from ncrhub4 by ncrhub1.NCR.COM id aa15133; 8 Mar 94 17:55 EST > Received: by ncrhub4.NCR.COM; 8 Mar 94 17:54:59 EST > Received: by dayhub.DaytonOH.NCR.COM; 8 Mar 94 17:54:34 EST > Subject: Re: Adding host authentication to rdist > To: Don Beusee > Date: Tue, 8 Mar 1994 17:37:19 -0500 (EST) > From: Tom Moore > Cc: rdist-dev@usc.edu > In-Reply-To: <199403082214.OAA24239@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 02:14:36 pm > X-Mailer: ELM [version 2.4 PL23] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 1351 > Message-ID: <9403081755.aa15133@ncrhub1.NCR.COM> > Status: R > > Don Beusee writes: > > > > Mike just got rdist to be a non-setuid program. I think it would be better > > to use a front end wrapper to rsh and have rdist call that. This will allow > > you to have a more secure rsh as well. > > I don't believe that rdist needs to be setuid rather I just need to change > where to look for the rdist password file to allow each user (even root) > to have one. I used one file before since I was only worried about making > updates as root and it was already running as root. > > > Be careful doing any authentication based on dates/times. What happens when > > you try to connect to a host in a different timezone? Its not real clear to > > me how this works (exactly what the date does). Maybe you could show me a > > handshake that fails and highlight the difference. > > The time used in the handshake is immaterial just as long as the challenge > string is constantly changing to prevent replay. The method is quite simple. > > 1. I pick some time string and encrypt it. > 2. I ask the remote to encrypt it also. > 3. I compare the results. > > The remote does steps 1-3 for itself to authenticate the local machine. > > I passed this by Bill Cheswick at Bell Labs and it should be quite immune to > spoofing. He suggested that I might possible use a millisecond or > microsecond time string. > > -- > Tom Moore, Electronic Information Interchange > > -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Wed Mar 9 08:04:17 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26688; Wed, 9 Mar 94 08:04:17 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id IAA03879; Wed, 9 Mar 1994 08:02:53 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id IAA05756; Wed, 9 Mar 1994 08:00:30 -0800 Message-Id: <199403091600.IAA05756@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 08:00:30 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu But it goes on the wire, readable by anyone sniffing it. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 06:33:56 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id GAA04956 for ; Wed, 9 Mar 1994 06:33:56 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id GAA27736; Wed, 9 Mar 1994 06:36:12 -0800 Message-Id: <199403091436.GAA27736@gatekeeper.us.oracle.com> Subject: Re: Adding host authentication to rdist To: dbeusee@us (Don Beusee) Date: Wed, 9 Mar 1994 09:36:08 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403090403.UAA28613@dbeusee.us.oracle.com> from "Don Beusee" at Mar 8, 94 08:03:07 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 221 Status: R Don Beusee writes: > > Is the password in your file plain text or encrypted? > The passwords in the file are plain text but the file is only readable by the owner. -- Tom Moore, Electronic Information Interchange From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 08:21:02 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27239; Wed, 9 Mar 94 08:21:02 PST Message-Id: <9403091621.AA27239@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Wed, 9 Mar 1994 11:20:58 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403091600.IAA05756@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 08:00:30 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 632 Don Beusee writes: > > But it goes on the wire, readable by anyone sniffing it. > No it doesn't. The process works this way: Hosts A and B each have a file containing the password that they have agreed to use. It is the same password. A sends some plain text string to B. B encrypts the string with it's copy of the password and sends back the encrypted string. A encrypts the same string with it's copy of the password and compares it to what B sent. If they match then A is sure of the identity of B. The process is repeated by B to verify the identity of A. -- Tom Moore, Electronic Information Interchange From rsalz@osf.org Wed Mar 9 09:04:43 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA28983; Wed, 9 Mar 94 09:04:43 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA15844; Wed, 9 Mar 94 12:04:38 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA17755; Wed, 9 Mar 94 12:03:41 -0500 Date: Wed, 9 Mar 94 12:03:41 -0500 From: rsalz@osf.org Message-Id: <9403091703.AA17755@sulphur.osf.org> To: dbeusee@us.oracle.com, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu Dopnm' Don't use the time but instead use some random string. Using the time makes your method too susceptible to "known plaintext" attacks. From dbeusee@us.oracle.com Wed Mar 9 09:44:05 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00940; Wed, 9 Mar 94 09:44:05 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id JAA12225; Wed, 9 Mar 1994 09:42:13 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id JAA06806; Wed, 9 Mar 1994 09:39:53 -0800 Message-Id: <199403091739.JAA06806@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 09:39:53 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu This is a much better way to describe the process, thanks! The only problem now, is that any host you wish to have this authentication on will have the password. This means any machine it lives on will be subject to the people with root access. They can take that password, bring down a workstation and come up with the interesting IP and masquerade as that host. Lets say HostA does pushes to HostB. HostB has root access to some people. Those people can copy the file containing the password to HostC, then bring up HostC with HostA's IP address and presto. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 08:18:51 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id IAA05851 for ; Wed, 9 Mar 1994 08:18:50 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id IAA05061; Wed, 9 Mar 1994 08:21:01 -0800 Message-Id: <199403091621.IAA05061@gatekeeper.us.oracle.com> Subject: Re: Adding host authentication to rdist To: dbeusee@us (Don Beusee) Date: Wed, 9 Mar 1994 11:20:58 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403091600.IAA05756@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 08:00:30 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 632 Status: RO Don Beusee writes: > > But it goes on the wire, readable by anyone sniffing it. > No it doesn't. The process works this way: Hosts A and B each have a file containing the password that they have agreed to use. It is the same password. A sends some plain text string to B. B encrypts the string with it's copy of the password and sends back the encrypted string. A encrypts the same string with it's copy of the password and compares it to what B sent. If they match then A is sure of the identity of B. The process is repeated by B to verify the identity of A. -- Tom Moore, Electronic Information Interchange From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 11:48:39 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05547; Wed, 9 Mar 94 11:48:39 PST Message-Id: <9403091948.AA05547@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Wed, 9 Mar 1994 14:48:31 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403091739.JAA06806@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 09:39:53 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2006 Don Beusee writes: > > This is a much better way to describe the process, thanks! > > The only problem now, is that any host you wish to have this authentication on > will have the password. This means any machine it lives on will be subject to > the people with root access. They can take that password, bring down a > workstation and come up with the interesting IP and masquerade as that host. > > Lets say HostA does pushes to HostB. HostB has root access to some people. > Those people can copy the file containing the password to HostC, then bring > up HostC with HostA's IP address and presto. The situation now is that if HostC can come up with HostA's IP address it can push files to HostB. That is the concern. With the addition of authentication, someone would need root password on HostA or HostB. If they have that, anything else we do is pointless. Given that the root password is guarded, the authenticated version is much more secure. The earlier suggestion that such authentication be put in rsh is probably the better long term solution but I don't see it happening soon at least at any of my sites. The implementation in rdist is relatively painless and works now. Another point is while the current implementation uses a single password file, it needs to be changed now that rdist does not run setuid to root. I see a more general implementation as allowing each user to have their own .rdist file for passwords. When any user pushs files from HostA to HostB HostB checks for a .rdist file in the users HOME directory and if it exists and is readable only by the user and contains an entry for HostA, HostB initiates the authentication procedure. If not, just send the version string as before. I realize that this description is a bit simplistic but the point is to make such authentication available for those who want to use it without forcing it on those who don't. It appears to be a low cost option to me. -- Tom Moore, Electronic Information Interchange From rsalz@osf.org Wed Mar 9 12:03:21 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06031; Wed, 9 Mar 94 12:03:21 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA16717; Wed, 9 Mar 94 15:03:12 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA19069; Wed, 9 Mar 94 15:02:14 -0500 Date: Wed, 9 Mar 94 15:02:14 -0500 From: rsalz@osf.org Message-Id: <9403092002.AA19069@sulphur.osf.org> To: rsalz@osf.org, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu >How do I generate a >random< string? rand, random, rand48, wahtever.... From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 12:05:05 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06183; Wed, 9 Mar 94 12:05:05 PST Message-Id: <9403092005.AA06183@usc.edu> Subject: Re: Adding host authentication to rdist To: rsalz@osf.org Date: Wed, 9 Mar 1994 14:54:36 -0500 (EST) From: "Tom Moore" Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu In-Reply-To: <9403091703.AA17755@sulphur.osf.org> from "rsalz@osf.org" at Mar 9, 94 12:03:41 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 rsalz@osf.org writes: > > Dopnm' > Don't use the time but instead use some random string. Using the time > makes your method too susceptible to "known plaintext" attacks. > I agree but I don't know how to generate such a string. Given that the attacker has the rdist code, it seems that anything I do is not truely random and is still subject to the same attack. How do I generate a >random< string? -- Tom Moore, Electronic Information Interchange From rsalz@osf.org Wed Mar 9 12:16:15 1994 Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06694; Wed, 9 Mar 94 12:16:15 PST Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA18861; Wed, 9 Mar 94 15:16:10 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA19397; Wed, 9 Mar 94 15:15:12 -0500 Date: Wed, 9 Mar 94 15:15:12 -0500 From: rsalz@osf.org Message-Id: <9403092015.AA19397@sulphur.osf.org> To: rsalz@osf.org, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu you do the best you can. true RNG often implies a hardware device. :-) Take the low bits of the time, or in the PID shifted up a bit and use that as the seed. Avoid rand; I don't recall if rand48 or lrand or random is best. It will be hard to know the seed assuming the user can't do a "ps" on host B it won't know the pid. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 12:20:03 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06775; Wed, 9 Mar 94 12:20:03 PST Message-Id: <9403092020.AA06775@usc.edu> Subject: Re: Adding host authentication to rdist To: rsalz@osf.org Date: Wed, 9 Mar 1994 15:10:53 -0500 (EST) From: "Tom Moore" Cc: dbeusee@us.oracle.com, rdist-dev@usc.edu In-Reply-To: <9403092002.AA19069@sulphur.osf.org> from "rsalz@osf.org" at Mar 9, 94 03:02:14 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 rsalz@osf.org writes: > > >How do I generate a >random< string? > > rand, random, rand48, wahtever.... I beliee that there is some controversy about whether these are random. Given knowledge of the seed, is the output random? Given knowledge of how the seed is chosen, is the subset of probable seeds small enough to still mount a successful attack? -- Tom Moore, Electronic Information Interchange From neal@ctd.comsat.com Wed Mar 9 12:36:24 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07398; Wed, 9 Mar 94 12:36:24 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0peUzO-0002fOC; Wed, 9 Mar 94 15:36 EST Message-Id: Date: Wed, 9 Mar 94 15:36 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist In-Reply-To: <9403092020.AA06775@usc.edu> References: <9403092002.AA19069@sulphur.osf.org> <9403092020.AA06775@usc.edu> >>>>> "Tom" == Tom Moore writes: Tom> rsalz@osf.org writes: >> >How do I generate a >random< string? >> >> rand, random, rand48, wahtever.... Tom> I beliee that there is some controversy about whether these Tom> are random. Given knowledge of the seed, is the output Tom> random? Given knowledge of how the seed is chosen, is the Tom> subset of probable seeds small enough to still mount a Tom> successful attack? Not to beat a dead horse, but NONE of these are randome at all, they are all pseudo-random. rand is the worst, random or rand48 are better. Better still is ACG for gnu libg++. From neal@ctd.comsat.com Wed Mar 9 12:41:54 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07601; Wed, 9 Mar 94 12:41:54 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0peV4j-0002fOC; Wed, 9 Mar 94 15:41 EST Message-Id: Date: Wed, 9 Mar 94 15:41 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist In-Reply-To: References: <9403092002.AA19069@sulphur.osf.org> <9403092020.AA06775@usc.edu> How does this sound? A and B agree in advance on a secret key K(ab). A sends a random number to B. B encrypts this using DES, using K(ab) and sends the encrypted result back to B. B verifies A's identity by decrypting using K(ab). From dbeusee@us.oracle.com Wed Mar 9 12:49:32 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07901; Wed, 9 Mar 94 12:49:32 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id MAA29697; Wed, 9 Mar 1994 12:48:14 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id MAA09219; Wed, 9 Mar 1994 12:45:55 -0800 Message-Id: <199403092045.MAA09219@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 12:45:55 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu How are you going to force that the file is only readable by the owner? I realize this is another level of security on top of the existing stuff, but if you start spreading it all over, its usefulness might deteriorate. Pls realize that all it takes is for someone to break into a system one time as the owner of the file to get the password. You might want to make it more secure at some point. Just some constructive comments... Regards, Don. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 11:46:21 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id LAA08459 for ; Wed, 9 Mar 1994 11:46:20 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id LAA24043; Wed, 9 Mar 1994 11:48:36 -0800 Message-Id: <199403091948.LAA24043@gatekeeper.us.oracle.com> Subject: Re: Adding host authentication to rdist To: dbeusee@us (Don Beusee) Date: Wed, 9 Mar 1994 14:48:31 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403091739.JAA06806@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 09:39:53 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2006 Status: R Don Beusee writes: > > This is a much better way to describe the process, thanks! > > The only problem now, is that any host you wish to have this authentication on > will have the password. This means any machine it lives on will be subject to > the people with root access. They can take that password, bring down a > workstation and come up with the interesting IP and masquerade as that host. > > Lets say HostA does pushes to HostB. HostB has root access to some people. > Those people can copy the file containing the password to HostC, then bring > up HostC with HostA's IP address and presto. The situation now is that if HostC can come up with HostA's IP address it can push files to HostB. That is the concern. With the addition of authentication, someone would need root password on HostA or HostB. If they have that, anything else we do is pointless. Given that the root password is guarded, the authenticated version is much more secure. The earlier suggestion that such authentication be put in rsh is probably the better long term solution but I don't see it happening soon at least at any of my sites. The implementation in rdist is relatively painless and works now. Another point is while the current implementation uses a single password file, it needs to be changed now that rdist does not run setuid to root. I see a more general implementation as allowing each user to have their own .rdist file for passwords. When any user pushs files from HostA to HostB HostB checks for a .rdist file in the users HOME directory and if it exists and is readable only by the user and contains an entry for HostA, HostB initiates the authentication procedure. If not, just send the version string as before. I realize that this description is a bit simplistic but the point is to make such authentication available for those who want to use it without forcing it on those who don't. It appears to be a low cost option to me. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Wed Mar 9 12:53:34 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08036; Wed, 9 Mar 94 12:53:34 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id MAA29848; Wed, 9 Mar 1994 12:50:51 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id MAA09234; Wed, 9 Mar 1994 12:48:32 -0800 Message-Id: <199403092048.MAA09234@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 12:48:32 -0800 From: Don Beusee To: rsalz@osf.org, tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu Include time(0) into the seed. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 12:08:42 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id MAA08685 for ; Wed, 9 Mar 1994 12:08:42 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id MAA26358; Wed, 9 Mar 1994 12:10:59 -0800 Message-Id: <199403092010.MAA26358@gatekeeper.us.oracle.com> Subject: Re: Adding host authentication to rdist To: rsalz@osf.org Date: Wed, 9 Mar 1994 15:10:53 -0500 (EST) From: "Tom Moore" Cc: dbeusee@us, rdist-dev@usc.edu In-Reply-To: <9403092002.AA19069@sulphur.osf.org> from "rsalz@osf.org" at Mar 9, 94 03:02:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 Status: R rsalz@osf.org writes: > > >How do I generate a >random< string? > > rand, random, rand48, wahtever.... I beliee that there is some controversy about whether these are random. Given knowledge of the seed, is the output random? Given knowledge of how the seed is chosen, is the subset of probable seeds small enough to still mount a successful attack? -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Wed Mar 9 13:06:17 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08492; Wed, 9 Mar 94 13:06:17 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id NAA01181; Wed, 9 Mar 1994 13:06:15 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id NAA09530; Wed, 9 Mar 1994 13:03:56 -0800 Message-Id: <199403092103.NAA09530@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 13:03:56 -0800 From: Don Beusee To: neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist How random do you need to get? How can a human predict the results of even rand()? From neal@ctd.comsat.com Wed Mar 9 12:56:16 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id MAA09334 for ; Wed, 9 Mar 1994 12:56:16 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id MAA00620; Wed, 9 Mar 1994 12:58:30 -0800 Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07398; Wed, 9 Mar 94 12:36:24 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0peUzO-0002fOC; Wed, 9 Mar 94 15:36 EST Message-Id: Date: Wed, 9 Mar 94 15:36 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist In-Reply-To: <9403092020.AA06775@usc.edu> References: <9403092002.AA19069@sulphur.osf.org> <9403092020.AA06775@usc.edu> Status: R >>>>> "Tom" == Tom Moore writes: Tom> rsalz@osf.org writes: >> >How do I generate a >random< string? >> >> rand, random, rand48, wahtever.... Tom> I beliee that there is some controversy about whether these Tom> are random. Given knowledge of the seed, is the output Tom> random? Given knowledge of how the seed is chosen, is the Tom> subset of probable seeds small enough to still mount a Tom> successful attack? Not to beat a dead horse, but NONE of these are randome at all, they are all pseudo-random. rand is the worst, random or rand48 are better. Better still is ACG for gnu libg++. From karels@redrock.BSDI.COM Wed Mar 9 13:07:10 1994 Return-Path: Received: from redrock.BSDI.COM by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08522; Wed, 9 Mar 94 13:07:10 PST Received: from redrock.BSDI.COM (localhost.BSDI.COM [127.0.0.1]) by redrock.BSDI.COM (8.6.5/8.6.5) with ESMTP id PAA09453; Wed, 9 Mar 1994 15:05:44 -0600 Message-Id: <199403092105.PAA09453@redrock.BSDI.COM> To: "Tom Moore" Cc: rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist In-Reply-To: Your message of Wed, 09 Mar 1994 14:48:31 -0500. <9403091948.AA05547@usc.edu> Date: Wed, 09 Mar 1994 15:05:43 -0600 From: Mike Karels > The earlier suggestion that such authentication be put in rsh is probably > the better long term solution but I don't see it happening soon at least > at any of my sites. Authentication schemes are sufficiently difficult to get right that inventing a new one for each program seems quite wrong. As someone said earlier, using an existing authentication system such as Kerberos is better than inventing one. Putting the authentication in rsh rather than rdist makes it useful for other things too. One problem in using Kerberos (version 4 at least) as implemented in rsh is that a ticket-granting ticket needs to be obtained by typing a passwd, and the ticket has a limited lifetime. This doesn't work well for programs that run from cron in the middle of the night. Someone at Berkeley modified rdist-classic to use the Kerberos equivalent of rcmd() using the system's own key for root users. This seems to handle most of the uses. (The code would be better in rsh, of course.) Mike From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 13:23:28 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09145; Wed, 9 Mar 94 13:23:28 PST Message-Id: <9403092123.AA09145@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Wed, 9 Mar 1994 16:23:22 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403092045.MAA09219@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 12:45:55 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 868 Don Beusee writes: > > How are you going to force that the file is only readable by the owner? Well the owner and root just like .rhosts. If rdist detects the wrong permissions, it assumes the worst and does not allow the update to proceed. > I realize this is another level of security on top of the existing stuff, > but if you start spreading it all over, its usefulness might deteriorate. > > Pls realize that all it takes is for someone to break into a system one time > as the owner of the file to get the password. > > You might want to make it more secure at some point. > > Just some constructive comments... > > Regards, > Don. Again, given that they can break in as the file owner or root, then anything we do in rdist seems immaterial. They can change files directly rather than through rdist. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Wed Mar 9 14:17:05 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11377; Wed, 9 Mar 94 14:17:05 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id OAA07107; Wed, 9 Mar 1994 14:15:47 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA10294; Wed, 9 Mar 1994 14:13:22 -0800 Message-Id: <199403092213.OAA10294@dbeusee.us.oracle.com> Date: Wed, 9 Mar 1994 14:13:22 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: rdist-dev@usc.edu > Well the owner and root just like .rhosts. If rdist detects the wrong > permissions, it assumes the worst and does not allow the update to > proceed. Whether the file has correct permissions or not, the password becomes visible to EVERYONE on the system if it happens to get a+r permissions, accidentally or otherwise, blowing a big hole in this scheme. Regards, Don. From tmoore@fievel.DaytonOH.NCR.COM Wed Mar 9 13:43:32 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id NAA10019 for ; Wed, 9 Mar 1994 13:43:31 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id NAA04528; Wed, 9 Mar 1994 13:45:42 -0800 Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09145; Wed, 9 Mar 94 13:23:28 PST Message-Id: <9403092123.AA09145@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us (Don Beusee) Date: Wed, 9 Mar 1994 16:23:22 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403092045.MAA09219@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 12:45:55 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 868 Status: R Don Beusee writes: > > How are you going to force that the file is only readable by the owner? Well the owner and root just like .rhosts. If rdist detects the wrong permissions, it assumes the worst and does not allow the update to proceed. > I realize this is another level of security on top of the existing stuff, > but if you start spreading it all over, its usefulness might deteriorate. > > Pls realize that all it takes is for someone to break into a system one time > as the owner of the file to get the password. > > You might want to make it more secure at some point. > > Just some constructive comments... > > Regards, > Don. Again, given that they can break in as the file owner or root, then anything we do in rdist seems immaterial. They can change files directly rather than through rdist. -- Tom Moore, Electronic Information Interchange From rouilj@cs.umb.edu Wed Mar 9 14:41:41 1994 Return-Path: Received: from cs.umb.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12168; Wed, 9 Mar 94 14:41:41 PST Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA27830 (5.65c/IDA-1.4.4 for ); Wed, 9 Mar 1994 17:41:36 -0500 Message-Id: <199403092241.AA27830@cs.umb.edu> To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: Adding host authentication to rdist In-Reply-To: Your message of "Wed, 09 Mar 1994 12:45:55 PST." <199403092045.MAA09219@dbeusee.us.oracle.com> Date: Wed, 09 Mar 1994 17:41:35 -0500 From: "John P. Rouillard" In message <199403092045.MAA09219@dbeusee.us.oracle.com>, Don Beusee writes: > How are you going to force that the file is only readable by the owner? > > I realize this is another level of security on top of the existing stuff, > but if you start spreading it all over, its usefulness might deteriorate. > > Pls realize that all it takes is for someone to break into a system one time > as the owner of the file to get the password. > > You might want to make it more secure at some point. > > Just some constructive comments... Maybe I am missing something, but why not just change rsh to something like: /usr/local/bin/ersh where ersh is something like: host=$1 shift; if [ "$1" = "-l" ]; then user=$2 shift; shift; else user=$USER fi (rsh $host -l $user /bin/sh << EOF checkphrase $randomphrase sleep 20 $1 EOF ) | check_encrypt $randomphrase check_encrypt should encrypt $randomphrase, grab the first line to be returned from the rsh, and compare the two. If they don't compare properly, then exit. That should cause the remote shell to be torn down. In any case, rdist will never complete the handshake since all of its output goes to neverneverland. If the string does compare properly, then just shuffle bits from the rsh right out to the waiting rdist. If you have expect, or perl, you can do even better checking with less overhead. I can imagine even more exotic setups including using a single use password scheme to do a real authentication. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From raeburn@cygnus.com Wed Mar 9 17:23:37 1994 Return-Path: Received: from relay1.UU.NET by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20068; Wed, 9 Mar 94 17:23:37 PST Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwgob29800; Wed, 9 Mar 94 20:22:35 -0500 Received: from tweedledumb.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA25141; Wed, 9 Mar 94 17:22:27 PST From: raeburn@cygnus.com (Ken Raeburn) Received: from cujo.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA28537; Wed, 9 Mar 94 20:22:23 EST Received: by cujo.cygnus.com; id AA11536; Wed, 9 Mar 1994 20:22:22 -0500 Date: Wed, 9 Mar 1994 20:22:22 -0500 Message-Id: <9403100122.AA11536@cujo.cygnus.com> To: rdist-dev@usc.edu In-Reply-To: Mike Karels's message of Wed, 09 Mar 1994 15:05:43 -0600 <199403092105.PAA09453@redrock.BSDI.COM> Subject: Re: Adding host authentication to rdist Date: Wed, 09 Mar 1994 15:05:43 -0600 From: Mike Karels One problem in using Kerberos (version 4 at least) as implemented in rsh is that a ticket-granting ticket needs to be obtained by typing a passwd, and the ticket has a limited lifetime. This doesn't work well for programs that run from cron in the middle of the night. Someone at Berkeley modified rdist-classic to use the Kerberos equivalent of rcmd() using the system's own key for root users. This seems to handle most of the uses. (The code would be better in rsh, of course.) I haven't looked at the Berkeley version of Kerberos in a while, but the MIT version includes a program "ksrvtgt", which I wrote when I was at MIT for dealing with just this problem. It does require running two programs instead of one, unfortunately, but that does make it useful with more than just rsh or rdist. You'd use something like this, run via cron on host `master': #!/bin/sh set -e KRBTKFILE=/tmp/tkt0_rdist export KRBTKFILE ksrvtgt rcmd master exec rdist foo bar -use-kerberos-rsh -whatever Any principal name can be used, as long as its key is available on the master host. Some services, especially those not run as root, will use different principal names, but may still want to initiate authenticated connections. From dbeusee@us.oracle.com Thu Mar 10 10:08:47 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18330; Thu, 10 Mar 94 10:08:47 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id KAA22426; Thu, 10 Mar 1994 10:08:41 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id KAA22513 for rdist-dev@usc.edu; Thu, 10 Mar 1994 10:06:22 -0800 Message-Id: <199403101806.KAA22513@dbeusee.us.oracle.com> Date: Thu, 10 Mar 1994 10:06:22 -0800 From: Don Beusee To: rdist-dev@usc.edu Subject: rdist semantics I've been researching the problem with rdist hard-links when: (dir1 dir2) -> host install dir3; I found the reason for rdist's difficulty, and I see a semantics dilemma. I noticed that rdist will treat the following cases differently. Lets say dir1 contains file1 and dir2 contains file2. case1: (dir1 dir2) -> host install dir3; case2: dir1 -> host install dir3; dir2 -> host install dir3; case1 will put dir1 and dir2 under dir3. Case2 puts the CONTENTS of dir1 and dir2 in dir3: case1 output: dir3/ dir1/ file1 dir2/ file2 case2 output: dir3/ file1 file2 Is it correct for rdist to treat the 2 cases this way so that it matters if the source list contains 1 dir or multiple directories? Case2 is not consistent with other commands like cp -r. This also makes rdist a little inconsistent. Of course if we fix the semantic problems, rdist will not be compatible with old versions, causing havic with existing distfile's. I suppose its too late to fix something like this. Maybe we don't want to, since this gives us more flexibility. Comments? I should have a patch ready later today to fix the problem with hardlinks in Case1 when hardlinks exist in dir1 or dir2 (or any level underneath those dirs). Regards, Don. From dbeusee@us.oracle.com Thu Mar 10 12:50:35 1994 Return-Path: Received: from keymaster.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24380; Thu, 10 Mar 94 12:50:35 PST Received: from dbeusee.us.oracle.com by keymaster.us.oracle.com with ESMTP (8.6.4/37.7) id MAA00573; Thu, 10 Mar 1994 12:50:30 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id MAA24664; Thu, 10 Mar 1994 12:46:55 -0800 Message-Id: <199403102046.MAA24664@dbeusee.us.oracle.com> Date: Thu, 10 Mar 1994 12:46:55 -0800 From: Don Beusee To: mcooper@usc.edu, rdist-dev@usc.edu Subject: hardlink patch for 6.1Beta3 The following patch fixes the latest hardlink bug with rdist which existed in all V6 releases. diff -r1.1 client.c 79a80 > extern struct namelist *filelist; 99c100 < if (cp == NULL) --- > if ((cp == NULL) || (filelist->n_next != NULL)) diff -r1.1 docmd.c 53c53 < struct subcmd *subcmds; /* list of sub-commands for --- > struct subcmd *subcmds; /* list of sub-commands for 54a55 > struct namelist *filelist; /* list of source files */ 469a471 > filelist = files; 750a753,754 > filelist = files; > This runs clean on my test suit! I even tested hardlinks a couple of levels deep. Let me know if this fails for anyone. It shouldn't. Regards, Don. From dbeusee@us.oracle.com Thu Mar 10 14:07:34 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA27785; Thu, 10 Mar 94 14:07:34 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id OAA11290; Thu, 10 Mar 1994 14:07:30 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA25716; Thu, 10 Mar 1994 14:05:10 -0800 Message-Id: <199403102205.OAA25716@dbeusee.us.oracle.com> Date: Thu, 10 Mar 1994 14:05:10 -0800 From: Don Beusee To: rouilj@cs.umb.edu Subject: Re: hardlink patch for 6.1Beta3 Cc: rdist-dev@usc.edu Yeah, I just pasted it into my mail window... Use can use patch -l. From rouilj@cs.umb.edu Thu Mar 10 13:02:19 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id NAA25173 for ; Thu, 10 Mar 1994 13:02:18 -0800 Received: from cs.umb.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id NAA06185; Thu, 10 Mar 1994 13:04:35 -0800 Received: from cs.umb.edu by cs.umb.edu with SMTP id AA25788 (5.65c/IDA-1.4.4 for ); Thu, 10 Mar 1994 16:04:33 -0500 Message-Id: <199403102104.AA25788@cs.umb.edu> To: Don Beusee Subject: Re: hardlink patch for 6.1Beta3 In-Reply-To: Your message of "Thu, 10 Mar 1994 12:46:55 PST." <199403102046.MAA24664@dbeusee.us.oracle.com> Date: Thu, 10 Mar 1994 16:04:32 -0500 From: "John P. Rouillard" Status: R Well the patch application failed with the folowing reject files: docmd.c.rej: *************** *** 53 - struct subcmd *subcmds; /* list of sub-commands for --- 53 ----- + struct subcmd *subcmds; /* list of sub-commands for client.c.rej *************** *** 99 - if (cp == NULL) --- 100 ----- + if ((cp == NULL) || (filelist->n_next != NULL)) I think they were just whitespace errors. I finished applying the patch by hand and will give a shot to testing the tools fully tonite. In message <199403102046.MAA24664@dbeusee.us.oracle.com>, Don Beusee writes: > The following patch fixes the latest hardlink bug with rdist which > existed > in all V6 releases. > > diff -r1.1 client.c > 79a80 > > extern struct namelist *filelist; > 99c100 > < if (cp == NULL) > --- > > if ((cp == NULL) || (filelist->n_next != NULL)) > > diff -r1.1 docmd.c > 53c53 > < struct subcmd *subcmds; /* list of > sub-commands for > --- > > struct subcmd *subcmds; /* list of sub-comm > ands for > 54a55 > > struct namelist *filelist; /* list of > source files */ > 469a471 > > filelist = files; > 750a753,754 > > filelist = files; > > > > This runs clean on my test suit! I even tested hardlinks a couple > of levels > deep. Let me know if this fails for anyone. It shouldn't. > > Regards, > Don. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From dbeusee@us.oracle.com Thu Mar 10 20:30:38 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17631; Thu, 10 Mar 94 20:30:38 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id UAA08131; Thu, 10 Mar 1994 20:30:35 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id UAA29965; Thu, 10 Mar 1994 20:28:15 -0800 Message-Id: <199403110428.UAA29965@dbeusee.us.oracle.com> Date: Thu, 10 Mar 1994 20:28:15 -0800 From: Don Beusee To: aad@lovecraft.amd.com Subject: updated hardlink patch for 6.1Beta3 / replaces previous patch Cc: mcooper@usc.edu, rdist-dev@usc.edu I reproduced this and added it to my test suit. This new patch replaces the previous one and passes my tests. This is a shar file and not pasted - white space properly preserved (tabs, etc). Run patch on the 2 files from the top rdist release directory. The previous patch did not account for full pathnames like the following: (/path1/dir1 /path2/dir2) -> install /path3/dir3; Let me know how it goes... Regards, Don. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # hardlink.patch1 # hardlink.patch2 # sed 's/^X//' << 'SHAR_EOF' > hardlink.patch1 && X*** 1.1 1994/03/10 18:34:50 X--- src/client.c 1994/03/11 04:16:15 X*************** X*** 77,83 **** X--- 77,86 ---- X { X register char *lname, *cp; X static char buff[BUFSIZ]; X+ int srclen, pathlen; X+ char *p; X X+ X debugmsg(DM_MISC, X "remfilename: src=%s dest=%s path=%s rname=%s destdir=%d\n", X A(src), A(dest), A(path), A(rname), destdir); X*************** X*** 99,117 **** X if (cp == NULL) X (void) sprintf(buff, "%s/%s", dest, path); X else { X- int srclen, pathlen; X- X srclen = strlen(src); X pathlen = strlen(path); X if (srclen >= pathlen) X cp++; /* basename(path) */ X! else X! cp = path + srclen; /* path relative to src */ X if ((*cp != '/') && *cp) X (void) sprintf(buff, "%s/%s", dest, cp); X else X (void) sprintf(buff, "%s%s", dest, cp); X- lname = buff; X } X } else X strcpy(lname, dest); X--- 102,126 ---- X if (cp == NULL) X (void) sprintf(buff, "%s/%s", dest, path); X else { X srclen = strlen(src); X pathlen = strlen(path); X if (srclen >= pathlen) X cp++; /* basename(path) */ X! else { X! if (filelist->n_next == NULL) X! /* path relative to src */ X! cp = path + srclen; X! else { X! if ((p = strrchr(src, '/'))) X! cp = path + srclen - strlen(p); X! else X! cp = path; X! } X! } X if ((*cp != '/') && *cp) X (void) sprintf(buff, "%s/%s", dest, cp); X else X (void) sprintf(buff, "%s%s", dest, cp); X } X } else X strcpy(lname, dest); SHAR_EOF chmod 0644 hardlink.patch1 || echo "restore of hardlink.patch1 fails" sed 's/^X//' << 'SHAR_EOF' > hardlink.patch2 && X*** 1.1 1994/03/10 18:23:23 X--- src/docmd.c 1994/03/10 18:40:44 X*************** X*** 50,57 **** X #include X #include X X! struct subcmd *subcmds; /* list of sub-commands for X current cmd */ X extern struct cmd *cmds; /* Initialized by yyparse() */ X time_t lastmod; /* Last modify time */ X X--- 50,58 ---- X #include X #include X X! struct subcmd *subcmds; /* list of sub-commands for X current cmd */ X+ struct namelist *filelist; /* list of source files */ X extern struct cmd *cmds; /* Initialized by yyparse() */ X time_t lastmod; /* Last modify time */ X X*************** X*** 467,472 **** X--- 468,474 ---- X } X X subcmds = sbcmds; X+ filelist = files; X X n = 0; X for (sc = sbcmds; sc != NULL; sc = sc->sc_next) { X*************** X*** 748,753 **** X--- 750,757 ---- X } X X subcmds = sbcmds; X+ filelist = files; X+ X lastmod = stb.st_mtime; X if (!nflag && !IS_ON(options, DO_VERIFY)) X /* SHAR_EOF chmod 0644 hardlink.patch2 || echo "restore of hardlink.patch2 fails" exit 0 From Anthony.Datri@amd.com Thu Mar 10 16:03:18 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id QAA26796 for ; Thu, 10 Mar 1994 16:03:17 -0800 Received: from amdext.amd.com by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id QAA20940; Thu, 10 Mar 1994 16:05:36 -0800 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA27950 (5.67a/IDA-1.5+AMD for ); Thu, 10 Mar 1994 16:05:32 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA04128 (5.67a/IDA-1.5+AMD for ); Thu, 10 Mar 1994 16:05:29 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA05086; Thu, 10 Mar 94 17:11:35 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA04769; Thu, 10 Mar 94 17:13:11 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Thu, 10 Mar 1994 17:13:11 -0600 (CST) Message-Id: <8hTua7GXhG4B82nN5H@lovecraft.amd.com> Date: Thu, 10 Mar 1994 17:13:11 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dbeusee@us Subject: rdist patch Status: R man: ( /usr/local/man/man* /usr/local/man/whatis ) -> (proteus) install /export/local/hp700/man; now gives me Mar 10 17:05:03 dvorak rdist[4321]: proteus: REMOTE ERROR: /export/local/hp700/man/man1/gunzip.1: cannot link to /export/local/hp700/man//usr/local/man/man1/gzip.1: No such file or directory Before it would try to link to /export/local/hp700/man/gunzip.1. >--=8======================================================================--- From Anthony.Datri@amd.com Fri Mar 11 07:15:18 1994 Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13306; Fri, 11 Mar 94 07:15:18 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA15231 (5.67a/IDA-1.5+AMD for ); Fri, 11 Mar 1994 07:15:11 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA17514 (5.67a/IDA-1.5+AMD for ); Fri, 11 Mar 1994 07:15:10 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA20985; Fri, 11 Mar 94 09:13:43 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA07141; Fri, 11 Mar 94 09:15:24 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Fri, 11 Mar 1994 09:15:23 -0600 (CST) Message-Id: Date: Fri, 11 Mar 1994 09:15:23 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: question/problem wrt logging The man page lists various "types" for logging, but "none" doesn't seem to be among them, so I can't, for example, turn off all syslogging. >--=8======================================================================--- From tmoore@fievel.DaytonOH.NCR.COM Fri Mar 11 08:07:55 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA14706; Fri, 11 Mar 94 08:07:55 PST Message-Id: <9403111607.AA14706@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Fri, 11 Mar 1994 11:07:48 -0500 (EST) From: "Tom Moore" Cc: neal@ctd.comsat.com, rdist-dev@usc.edu In-Reply-To: <199403092103.NAA09530@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 01:03:56 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 608 Don Beusee writes: > > How random do you need to get? How can a human predict the results of even > rand()? > Given that the plaintext and cypher text both travel over the network, I am not sure of the value of a random plaintext string at all. The issue probably belongs in another discussion group anyway. At issue here is the inclusion of such authentication in rdist. Do we want it or not. It is not that difficult for me to put it in for my sites. I just thought that if it were of general interest, it should go in the public distribution. -- Tom Moore, Electronic Information Interchange From tmoore@fievel.DaytonOH.NCR.COM Fri Mar 11 08:20:05 1994 Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15075; Fri, 11 Mar 94 08:20:05 PST Message-Id: <9403111620.AA15075@usc.edu> Subject: Re: Adding host authentication to rdist To: dbeusee@us.oracle.com (Don Beusee) Date: Fri, 11 Mar 1994 11:10:43 -0500 (EST) From: "Tom Moore" Cc: rdist-dev@usc.edu In-Reply-To: <199403092213.OAA10294@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 02:13:22 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 546 Don Beusee writes: > > > Well the owner and root just like .rhosts. If rdist detects the wrong > > permissions, it assumes the worst and does not allow the update to > > proceed. > > Whether the file has correct permissions or not, the password becomes visible > to EVERYONE on the system if it happens to get a+r permissions, accidentally > or otherwise, blowing a big hole in this scheme. True but if that happens rdist can log an error and refuse to continue. Then you change passwords. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Fri Mar 11 09:42:01 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17774; Fri, 11 Mar 94 09:42:01 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id JAA22673; Fri, 11 Mar 1994 09:41:58 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id JAA08289; Fri, 11 Mar 1994 09:39:36 -0800 Message-Id: <199403111739.JAA08289@dbeusee.us.oracle.com> Date: Fri, 11 Mar 1994 09:39:36 -0800 From: Don Beusee To: aad@lovecraft.amd.com Subject: Re: updated hardlink patch for 6.1Beta3 / replaces previous patch Cc: rdist-dev@usc.edu Cool. From Anthony.Datri@amd.com Fri Mar 11 06:34:00 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id GAA06611 for ; Fri, 11 Mar 1994 06:34:00 -0800 Received: from amdext.amd.com by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id GAA09113; Fri, 11 Mar 1994 06:36:18 -0800 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA12597 (5.67a/IDA-1.5+AMD for ); Fri, 11 Mar 1994 06:36:16 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA16626 (5.67a/IDA-1.5+AMD for ); Fri, 11 Mar 1994 06:36:15 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA17144; Fri, 11 Mar 94 08:34:51 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA06730; Fri, 11 Mar 94 08:36:31 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Fri, 11 Mar 1994 08:36:30 -0600 (CST) Message-Id: <8hU87iyXhG4B82nH4=@lovecraft.amd.com> Date: Fri, 11 Mar 1994 08:36:30 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Don Beusee Subject: Re: updated hardlink patch for 6.1Beta3 / replaces previous patch In-Reply-To: <199403110428.UAA29965@dbeusee.us.oracle.com> References: <199403110428.UAA29965@dbeusee.us.oracle.com> Status: R >white space properly preserved (tabs, etc) I aliased patch to patch -l long ago. >Let me know how it goes... Success! proteus: updating host proteus proteus: /usr/local/adm/packages/sun.everytime: installing proteus: cmdspecial "/usr/adm/packages/sun.everytime ; /bin/rm /usr/adm/packages/sun.everytime " proteus: /usr/local/man/whatis: updating proteus: /usr/local/man/man1/zcat.1: installing proteus: /usr/local/man/man1/zcmp.1: installing proteus: /usr/local/man/man1/gunzip.1: installing proteus: /usr/local/man/man8/initdb.8: installing proteus: /usr/local/man/man8/domkov.8: installing proteus: /usr/local/man/man8/mkov.8: installing proteus: /usr/local/man/man8/batmkov.8: installing proteus: /usr/local/man/man8/expov.8: installing proteus: /usr/local/man/whatis: updating proteus: /usr/local/bin/rdist: updating proteus: /usr/local/bin/rdistd: updating proteus: updating of proteus finished >--=8======================================================================--- From dbeusee@us.oracle.com Fri Mar 11 09:51:40 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18289; Fri, 11 Mar 94 09:51:40 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id JAA23734; Fri, 11 Mar 1994 09:51:36 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id JAA08397; Fri, 11 Mar 1994 09:49:15 -0800 Message-Id: <199403111749.JAA08397@dbeusee.us.oracle.com> Date: Fri, 11 Mar 1994 09:49:15 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: Adding host authentication to rdist Cc: neal@ctd.comsat.com, rdist-dev@usc.edu I don't think rdist is the place for it. From tmoore@fievel.DaytonOH.NCR.COM Fri Mar 11 08:05:47 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id IAA07319 for ; Fri, 11 Mar 1994 08:05:45 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id IAA15109; Fri, 11 Mar 1994 08:07:59 -0800 Message-Id: <199403111607.IAA15109@gatekeeper.us.oracle.com> Subject: Re: Adding host authentication to rdist To: dbeusee@us (Don Beusee) Date: Fri, 11 Mar 1994 11:07:48 -0500 (EST) From: "Tom Moore" Cc: neal@ctd.comsat.com, rdist-dev@usc.edu In-Reply-To: <199403092103.NAA09530@dbeusee.us.oracle.com> from "Don Beusee" at Mar 9, 94 01:03:56 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 608 Status: R Don Beusee writes: > > How random do you need to get? How can a human predict the results of even > rand()? > Given that the plaintext and cypher text both travel over the network, I am not sure of the value of a random plaintext string at all. The issue probably belongs in another discussion group anyway. At issue here is the inclusion of such authentication in rdist. Do we want it or not. It is not that difficult for me to put it in for my sites. I just thought that if it were of general interest, it should go in the public distribution. -- Tom Moore, Electronic Information Interchange From dbeusee@us.oracle.com Fri Mar 11 09:56:14 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18508; Fri, 11 Mar 94 09:56:14 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id JAA24220; Fri, 11 Mar 1994 09:54:57 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id JAA08491; Fri, 11 Mar 1994 09:52:36 -0800 Message-Id: <199403111752.JAA08491@dbeusee.us.oracle.com> Date: Fri, 11 Mar 1994 09:52:36 -0800 From: Don Beusee To: tmoore@fievel.DaytonOH.NCR.COM Subject: Re: updated hardlink patch for 6.1Beta3 / replaces previous patch Cc: rdist-dev@usc.edu Cool. From tmoore@fievel.DaytonOH.NCR.COM Fri Mar 11 08:47:43 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id IAA07650 for ; Fri, 11 Mar 1994 08:47:43 -0800 Received: from fievel.DaytonOH.NCR.COM by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id IAA18282; Fri, 11 Mar 1994 08:50:01 -0800 Message-Id: <199403111650.IAA18282@gatekeeper.us.oracle.com> Subject: Re: updated hardlink patch for 6.1Beta3 / replaces previous patch To: dbeusee@us (Don Beusee) Date: Fri, 11 Mar 1994 11:49:56 -0500 (EST) From: "Tom Moore" In-Reply-To: <199403110428.UAA29965@dbeusee.us.oracle.com> from "Don Beusee" at Mar 10, 94 08:28:15 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 591 Status: R Don Beusee writes: > > I reproduced this and added it to my test suit. This new patch replaces the > previous one and passes my tests. This is a shar file and not pasted - white > space properly preserved (tabs, etc). Run patch on the 2 files from the top > rdist release directory. > > The previous patch did not account for full pathnames like the following: > (/path1/dir1 /path2/dir2) -> install /path3/dir3; > > Let me know how it goes... > > Regards, > Don. This fixes my test case and fixes my operational problem. Thanks. -- Tom Moore, Electronic Information Interchange From wls@astro.UMD.EDU Fri Mar 11 10:22:35 1994 Received: from lynx.astro.umd.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20466; Fri, 11 Mar 94 10:22:35 PST Return-Path: Received: by lynx.astro.umd.edu (5.65c/5.62mWLS) id AA22880; Fri, 11 Mar 1994 13:22:20 -0500 Date: Fri, 11 Mar 1994 13:22:20 -0500 From: wls@astro.UMD.EDU (William L. Sebok) Message-Id: <199403111822.AA22880@lynx.astro.umd.edu> To: rdist-dev@usc.edu Subject: Re: rdist semantics I believe that I brought up this point about a year ago, that rdist behaves semantically differently if differently if the source list contains one directory or two. This is particularly dangerous if the source list is produced by the expansion of a variable which may be the result of an operation on other variables. The behavior of rdist will change in possibly unintended ways if the number of items in the variable goes down to one. Bill Sebok Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu From mcooper@ucs.usc.edu Fri Mar 11 11:11:26 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22542; Fri, 11 Mar 94 11:11:26 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id LAA27003 for rdist-dev@usc.edu; Fri, 11 Mar 1994 11:11:25 -0800 Sender: "Michael A. Cooper" Date: Fri, 11 Mar 94 11:11:24 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: rdist auth Message-Id: I'm back from vacation and working on catching up on email... I feel that at this point rdist should continue to rely on some externel agent to make the connection to remote machines and worry about authentication. Now that you can specify _ANY_ externel agent, you can plug in your favorite agent (rsh, kerberos rsh, etc) and away you go. If some wonderful agent comes along that's clearly better than rsh that numerious people want to use with rdist, I will consider making it part of the official distribution or mentioning how to get it in the rdist distribution. I will try to get Don's latest hardlink patch into a release in the next few weeks, but it may take longer. Thanks again to Don for wading through all the hardlink crude in rdist! mike From neal@ctd.comsat.com Mon Mar 14 11:13:59 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07495; Mon, 14 Mar 94 11:13:59 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pgI5N-0002fOC; Mon, 14 Mar 94 14:13 EST Message-Id: Date: Mon, 14 Mar 94 14:13 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: rdist on hpux 1. Why do we have #define SETARGS in os-hpux.h? I thought setproctitle was a loser on hpux (caused special commands to fail mysteriously). 2. Not really important, but maybe #define POSIX_SIGNALS and #define ARG_TYPE ARG_STDARG are good things to do? I have built and tested these with hpux9.01 gcc-2.5.8 and they seem fine. From dbeusee@us.oracle.com Mon Mar 14 11:59:33 1994 Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09759; Mon, 14 Mar 94 11:59:33 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.5/37.7) id LAA26896; Mon, 14 Mar 1994 11:59:31 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id LAA20586; Mon, 14 Mar 1994 11:57:07 -0800 Message-Id: <199403141957.LAA20586@dbeusee.us.oracle.com> Date: Mon, 14 Mar 1994 11:57:07 -0800 From: Don Beusee To: neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: rdist on hpux SETARGS works on hpux since Beta2. From neal@ctd.comsat.com Mon Mar 14 11:40:36 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id LAA20485 for ; Mon, 14 Mar 1994 11:40:36 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.5/37.7) id LAA25437; Mon, 14 Mar 1994 11:42:55 -0800 Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07495; Mon, 14 Mar 94 11:13:59 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pgI5N-0002fOC; Mon, 14 Mar 94 14:13 EST Message-Id: Date: Mon, 14 Mar 94 14:13 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: rdist on hpux Status: R 1. Why do we have #define SETARGS in os-hpux.h? I thought setproctitle was a loser on hpux (caused special commands to fail mysteriously). 2. Not really important, but maybe #define POSIX_SIGNALS and #define ARG_TYPE ARG_STDARG are good things to do? I have built and tested these with hpux9.01 gcc-2.5.8 and they seem fine. From mcooper@ucs.usc.edu Mon Mar 14 12:14:21 1994 Return-Path: Received: from acamar.usc.edu ([128.125.18.1]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10698; Mon, 14 Mar 94 12:14:21 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id MAA19706; Mon, 14 Mar 1994 12:14:10 -0800 Sender: "Michael A. Cooper" Date: Mon, 14 Mar 94 12:14:09 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu Subject: Re: rdist on hpux In-Reply-To: Your message of Mon, 14 Mar 94 14:13 EST Message-Id: > 1. Why do we have > #define SETARGS > in os-hpux.h? I thought setproctitle was a loser on hpux (caused > special commands to fail mysteriously). > SETARGS should work for most platforms as of 6.1beta.2. > 2. Not really important, but maybe > > #define POSIX_SIGNALS > > and > > #define ARG_TYPE ARG_STDARG > In order to set ARG_STDARG you need an ANSI C compiler. I'm not sure if a working ANSI cc is bundled with most versions of HPUX that have come out in the last few years. Since ARG_VARARGS appears to work, sticking with the lowest common denominator seems like the safest bet. mike From philson@nmr.chem.umn.edu Mon Mar 14 12:25:41 1994 Return-Path: Received: from nmr.chem.umn.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11271; Mon, 14 Mar 94 12:25:41 PST Received: from localhost (philson@localhost) by nmr.chem.umn.edu (8.6.4/8.6.4) id OAA14407; Mon, 14 Mar 1994 14:30:45 -0600 Date: Mon, 14 Mar 1994 14:22:51 -0600 (CST) From: Steve Philson Subject: Mailbox access times To: rdist-dev@usc.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there any way to prevent rdist from updating the access times of the files it copies? I have just begun using it to mirror some of our mail server's directories onto another machine, but have had some complaints about the mailboxes having incorrect access times (which shows up as differences between new and old mail). I prefer using rdist to doing some kind of dump/restore across the net (it seems to be faster, and I suspect may be safer on live file systems), but am I perhaps using the program inappropriately? -------------------------------------------------------------------------- Steve Philson philson@nmr.chem.umn.edu Director NMR Lab 612-626-0297 Chemistry Dept. University of Minnesota From neal@ctd.comsat.com Mon Mar 14 14:05:05 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16701; Mon, 14 Mar 94 14:05:05 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pgKkw-0002fOC; Mon, 14 Mar 94 17:05 EST Message-Id: Date: Mon, 14 Mar 94 17:05 EST From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: neal@ctd.comsat.com (Neal Becker), rdist-dev@usc.edu Subject: Re: rdist on hpux In-Reply-To: References: >>>>> "Michael" == Michael A Cooper writes: Michael> SETARGS should work for most platforms as of 6.1beta.2. Thanks for the info. >> 2. Not really important, but maybe >> >> #define POSIX_SIGNALS >> >> and >> >> #define ARG_TYPE ARG_STDARG >> Michael> In order to set ARG_STDARG you need an ANSI C compiler. Michael> I'm not sure if a working ANSI cc is bundled with most Michael> versions of HPUX that have come out in the last few Michael> years. Since ARG_VARARGS appears to work, sticking with Michael> the lowest common denominator seems like the safest bet. You are correct. This still leaves POSIX_SIGNALS. I prefer to use this where applicable, since it disambiguates the symantics of signals. Any votes for/against? From mcooper@ucs.usc.edu Mon Mar 14 16:41:51 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23904; Mon, 14 Mar 94 16:41:51 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id QAA24268; Mon, 14 Mar 1994 16:41:43 -0800 Sender: "Michael A. Cooper" Date: Mon, 14 Mar 94 16:41:43 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: Steve Philson Cc: rdist-dev@usc.edu Subject: Re: Mailbox access times In-Reply-To: Your message of Mon, 14 Mar 1994 14:22:51 -0600 (CST) Message-Id: > Is there any way to prevent rdist from updating the access times of the > files it copies? I have just begun using it to mirror some of our mail > server's directories onto another machine, but have had some complaints > about the mailboxes having incorrect access times (which shows up as > differences between new and old mail). > > I prefer using rdist to doing some kind of dump/restore across the net (it > seems to be faster, and I suspect may be safer on live file systems), but > am I perhaps using the program inappropriately? > > -------------------------------------------------------------------------- > Steve Philson philson@nmr.chem.umn.edu > Director NMR Lab 612-626-0297 > Chemistry Dept. University of Minnesota > > > Rdist 6.* always sets the atime of files to the current time. I recall discussing this with Keith Bostic who seemed to think that atime should always be the access time on the _local_ host. Rdist 6.* does pass the atime from the client to the server, but the server doesn't use it. Rdist "classic" never passed the atime value, so it could never set it. mike From mosedale@genome.Stanford.EDU Tue Mar 15 00:36:04 1994 Return-Path: Received: from fafner.Stanford.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18255; Tue, 15 Mar 94 00:36:04 PST Received: from localhost (mosedale@localhost) by fafner.Stanford.EDU (8.6.4/8.6.4) id AAA26765 for rdist-dev@usc.edu; Tue, 15 Mar 1994 00:36:04 -0800 From: Dan Mosedale Message-Id: <199403150836.AAA26765@fafner.Stanford.EDU> Subject: Patches for DEC OSF/1 on Alpha To: rdist-dev@usc.edu Date: Tue, 15 Mar 1994 00:36:03 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5568 Here are patches to make rdist build properly on DEC's Alpha OSF/1. They've only been tried on version 1.3a, but they will probably work on other 1.x versions as well. With 2.x, your mileage may vary. Dan Mosedale mosedale@genome.Stanford.EDU To apply this patch: mkdir include/OSF_bug_kludgearound patch -p1 < thisfile diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/config/mf.osf1 alpha_osf13a/config/mf.osf1 *** dist/config/mf.osf1 Sat Mar 27 12:00:07 1993 --- alpha_osf13a/config/mf.osf1 Tue Mar 15 00:03:22 1994 *************** *** 48,50 **** --- 48,68 ---- # System libraries that we need to load. # #LIB_SYS = -lPW + + # + # The default install is not BSD style? + # + INSTALL = installbsd + + # + # This is a workaround for a bug in DEC OSF/1 1.x, where + # tries to include some files that live in /sys/include, and those files + # try to include other files which don't exist in a non-source distribution. + # Hopefully, this bug will have disappeared from OSF/1 2.x. + # + # Note that if you wish to use GCC, you will need to add the appropriate + # "fixincluded" directories (determine this with gcc -v) in before the + # "-I/usr/include". + # + INCLUDE_SYS = -I/usr/include -I/sys/include -I../include/OSF_bug_kludgearound + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/config/os-type alpha_osf13a/config/os-type *** dist/config/os-type Fri Feb 25 14:54:23 1994 --- alpha_osf13a/config/os-type Mon Mar 14 22:56:54 1994 *************** *** 85,90 **** --- 85,91 ---- "irix"*) OS="${osname}${osmajver}";; "ultrix"*) OS="${osname}${osmajver}";; "sunos"*) OS="${osname}${osmajver}";; + "osf1"*) OS="${osname}";; "bsd/386"*) OS=bsdi;; "aix"*) osmajver="`${uname} -v`" diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/cpus.h alpha_osf13a/include/OSF_bug_kludgearound/cpus.h *** dist/include/OSF_bug_kludgearound/cpus.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/cpus.h Tue Mar 15 00:30:48 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/lock_stats.h alpha_osf13a/include/OSF_bug_kludgearound/lock_stats.h *** dist/include/OSF_bug_kludgearound/lock_stats.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/lock_stats.h Tue Mar 15 00:25:54 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/mach_ldebug.h alpha_osf13a/include/OSF_bug_kludgearound/mach_ldebug.h *** dist/include/OSF_bug_kludgearound/mach_ldebug.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/mach_ldebug.h Tue Mar 15 00:26:01 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/mach_ltracks.h alpha_osf13a/include/OSF_bug_kludgearound/mach_ltracks.h *** dist/include/OSF_bug_kludgearound/mach_ltracks.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/mach_ltracks.h Tue Mar 15 00:26:05 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/rt_preempt.h alpha_osf13a/include/OSF_bug_kludgearound/rt_preempt.h *** dist/include/OSF_bug_kludgearound/rt_preempt.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/rt_preempt.h Tue Mar 15 00:26:13 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/rt_preempt_debug.h alpha_osf13a/include/OSF_bug_kludgearound/rt_preempt_debug.h *** dist/include/OSF_bug_kludgearound/rt_preempt_debug.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/rt_preempt_debug.h Tue Mar 15 00:26:19 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/OSF_bug_kludgearound/slock_stats.h alpha_osf13a/include/OSF_bug_kludgearound/slock_stats.h *** dist/include/OSF_bug_kludgearound/slock_stats.h Wed Dec 31 16:00:00 1969 --- alpha_osf13a/include/OSF_bug_kludgearound/slock_stats.h Tue Mar 15 00:26:24 1994 *************** *** 0 **** --- 1 ---- + diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/include/defs.h alpha_osf13a/include/defs.h *** dist/include/defs.h Thu Mar 3 16:03:42 1994 --- alpha_osf13a/include/defs.h Mon Mar 14 23:15:10 1994 *************** *** 88,93 **** --- 88,97 ---- #include #endif /* defined(STELLIX) */ + #if defined(__osf__) + #include + #endif + #if defined(ARG_TYPE) #if ARG_TYPE == ARG_STDARG #include diff -N -x rdistd -x rdist --text -x y.tab.h -x Makefile.local -x *.o -x gram.c -r -c dist/src/filesys-os.c alpha_osf13a/src/filesys-os.c *** dist/src/filesys-os.c Wed Dec 8 11:19:37 1993 --- alpha_osf13a/src/filesys-os.c Mon Mar 14 22:58:40 1994 *************** *** 51,57 **** --- 51,59 ---- #if FSI_TYPE == FSI_GETFSSTAT static struct statfs *mnt = NULL; + #ifndef __osf__ typedef u_long ulong; + #endif /* __osf__ */ #endif /* FSI_GETFSSTAT */ #if FSI_TYPE == FSI_MNTCTL From neal@ctd.comsat.com Tue Mar 15 05:39:01 1994 Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26926; Tue, 15 Mar 94 05:39:01 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pgZKb-0002fOC; Tue, 15 Mar 94 08:38 EST Message-Id: Date: Tue, 15 Mar 94 08:38 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu (Rdist Development Group) Subject: rdist on linux? Has anyone tried rdist on linux yet? Should be an easy port. If noone else has tried it I'll volunteer. From piela@hagar.aspentec.com Tue Mar 15 09:17:40 1994 Return-Path: Received: from hagar.aspentec.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04647; Tue, 15 Mar 94 09:17:40 PST Received: by hagar.aspentec.com (AIX 3.2/UCB 5.64/4.03) id AA42027; Tue, 15 Mar 1994 11:45:19 -0500 Date: Tue, 15 Mar 1994 11:45:19 -0500 From: piela@hagar.aspentec.com (PETER PIELA) Message-Id: <9403151645.AA42027@hagar.aspentec.com> To: rdist-dev@usc.edu Subject: File compression with rdist Has anyone modified rdist to do on-the-fly file compression? Thanks. Peter From mcooper@ucs.usc.edu Tue Mar 15 10:26:14 1994 Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08007; Tue, 15 Mar 94 10:26:14 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id KAA00487; Tue, 15 Mar 1994 10:26:12 -0800 Sender: "Michael A. Cooper" Date: Tue, 15 Mar 94 10:26:11 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu (Rdist Development Group) Subject: Re: rdist on linux? In-Reply-To: Your message of Tue, 15 Mar 94 08:38 EST Message-Id: Someone sent me a linux port. It's part of the next release. mike From tim.spencer@mccaw.com Tue Mar 15 11:15:27 1994 Return-Path: Received: from mccaw.com (wombat.mccaw.com) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10157; Tue, 15 Mar 94 11:15:27 PST Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA25102; Tue, 15 Mar 94 11:15:24 PST Received: from grape.nwest.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA29009; Tue, 15 Mar 94 11:15:23 PST Received: from kiwi by grape.nwest.mccaw.com (NX5.67d/McCaw NeXT-MS Mailer, NX3.0M) id AA16938; Tue, 15 Mar 94 11:15:22 -0800 From: Tim Spencer Message-Id: <9403151915.AA16938@grape.nwest.mccaw.com> Received: by kiwi.nwest.mccaw.com (NX5.67d/McCaw NeXT-SS Mailer, NX3.0X) id AA01711; Tue, 15 Mar 94 11:15:21 -0800 Date: Tue, 15 Mar 94 11:15:21 -0800 Received: by NeXT.Mailer (1.100.RR) Received: by NeXT Mailer (1.100.RR) To: piela@hagar.aspentec.com (PETER PIELA) Subject: Re: File compression with rdist Cc: rdist-dev@usc.edu Yes, but it's kinda a kludge... It doesn't do any stream compression like it should. It compresses the temporary file with a system() call to gzip or compress, and then does some re-evaluation of it's size and stuff, and then sends it over normally to be uncompressed on the other end. Unfortunately, it actually takes longer in quite a few cases than if you were to just send it uncompressed. I'm trying to distribute an application package that has lots of lzw compressed tiff images, and the overhead of compressing seems to not make up for the slight amount of traffic reduction. Plus, it loads the push half down quite a bit. It's sort of a hack, but it does work. Unfortunately, it was done on rdist version 6.0, so the patches that I would generate might not be all that current. But if you are interested, I can send the relevant source files. It also has some code in it that allows you to use rexec() rather than rcmd(), so you don't have to have trusted hosts laying around if you don't want to. It will ask you for a password using getpass(), or allow it to be given via a temporary password file that can be used in a script. Have fun! --- Tim Spencer: McCaw NeXT Technical Analyst tim.spencer@mccaw.com (206)915-5988 :-) NeXTMail welcome!! From stssram@st.unocal.com Tue Mar 15 12:03:34 1994 Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA12413; Tue, 15 Mar 94 12:03:34 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id MAA05080; Tue, 15 Mar 1994 12:03:20 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA05980; Tue, 15 Mar 94 12:03:19 PST Message-Id: <9403152003.AA05980@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Tue, 15 Mar 1994 12:03:13 -0800 In-Reply-To: Tim Spencer "Re: File compression with rdist" (Mar 15, 11:15) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Tim Spencer , piela@hagar.aspentec.com (PETER PIELA) Subject: Re: File compression with rdist Cc: rdist-dev@usc.edu, Arnold.Troeger@st.unocal.com On Mar 15, 11:15, Tim Spencer wrote: } Subject: Re: File compression with rdist > Yes, but it's kinda a kludge... It doesn't do any stream > compression like it should. It compresses the temporary file with a > system() call to gzip or compress, and then does some re-evaluation of it's > size and stuff, and then sends it over normally to be uncompressed on the > other end. Unfortunately, it actually takes longer in quite a few cases > than if you were to just send it uncompressed. I'm trying to distribute an > application package that has lots of lzw compressed tiff images, and the > overhead of compressing seems to not make up for the slight amount of > traffic reduction. Plus, it loads the push half down quite a bit. It's > sort of a hack, but it does work. I've been starting to think about doing something like this too. Problems I see ahead: I'd love to be able to set certain sorts of options on a per-host, rather than per-package or per-rdist-invocation (command line args) basis. There's no facility for doing this in a Distfile right now. Rationale: we have some network connections that are very much slower than others. I'd like to be able to set long timeouts and do compression on rdists to our slow network line hosts only. It wouldn't help on fast lines, I think, but the slow lines would benefit from the compression (and besides, keep the bandwidth usage lower on those slow lines). I'll post patches when I get around to doing this. > Unfortunately, it was done on rdist version 6.0, so the patches > that I would generate might not be all that current. But if you are > interested, I can send the relevant source files. I'd like to see it too. If the patches aren't too large, maybe you could post them to the list? -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From kim@tac.nyc.ny.us Wed Mar 16 12:20:12 1994 Return-Path: Received: from grendel.lut.fi ([157.24.101.173]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02139; Wed, 16 Mar 94 12:20:12 PST Received: from grendel.lut.fi (kim@localhost [127.0.0.1]) by grendel.lut.fi (8.6.7/8.6.6/1.16.kim) with ESMTP id WAA00765; Wed, 16 Mar 1994 22:20:02 +0200 (for ) Resent-Message-Id: <199403162020.WAA00765@grendel.lut.fi> Received: from grendel.lut.fi (grendel.lut.fi [157.24.101.173]) by lut.fi with ESMTP (8.6.5/8.6.5/1.14.kim) id WAA24577; Tue, 15 Mar 1994 22:55:53 +0200 (for ) Received: (from news@localhost) by grendel.lut.fi (8.6.7/8.6.6/1.16.kim) with netnews id WAA15194; Tue, 15 Mar 1994 22:30:03 +0200 (for rdist-dev@usc.edu) To: rdist-dev@usc.edu Date: Tue, 15 Mar 1994 20:22:04 GMT From: Kimmo.Suominen@lut.fi (Kimmo Suominen) Message-Id: Organization: Lappeenranta University of Technology, Finland Sender: usenet@tac.nyc.ny.us References: Subject: Re: rdist on hpux Resent-To: rdist-dev@usc.edu Resent-Date: Wed, 16 Mar 1994 22:20:01 +0200 Resent-From: Kimmo Suominen >>>>> "Neal" == Neal Becker writes: Neal> This still leaves POSIX_SIGNALS. I prefer to use this where Neal> applicable, since it disambiguates the symantics of signals. Neal> Any votes for/against? I've used POSIX signals with other software (most notably our TULP mailing list manager) without any problems for quite a long time, on both 8.0 and 9.0 (Series 800). Btw, I thought the HP ANSI-C compiler works very well - I've never bothered to put in gcc (and 2.5.x has been so broken). -- ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ( Kimmo Suominen "That's what I think" ) ( Trans-Atlantic Communications kim@tac.nyc.ny.us ) ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From rdist-dev-request Wed Mar 16 14:07:09 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08628; Wed, 16 Mar 94 14:07:10 PST Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08622; Wed, 16 Mar 94 14:07:09 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id OAA13970 for rdist-dev@usc.edu; Wed, 16 Mar 1994 14:07:07 -0800 Sender: "Michael A. Cooper" Date: Wed, 16 Mar 94 14:07:06 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: rdist-dev@usc.edu Subject: Test message Message-Id: This is a test message - please ignore. mike From rdist-dev-request@usc.edu Wed Mar 16 15:25:57 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13723; Wed, 16 Mar 94 15:26:00 PST Return-Path: Received: from fafner.Stanford.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA13718; Wed, 16 Mar 94 15:25:57 PST Received: from localhost (mosedale@localhost) by fafner.Stanford.EDU (8.6.4/8.6.4) id PAA19632 for rdist-dev@usc.edu; Wed, 16 Mar 1994 15:25:55 -0800 Date: Wed, 16 Mar 1994 15:25:55 -0800 From: Dan Mosedale Message-Id: <199403162325.PAA19632@fafner.Stanford.EDU> To: rdist-dev@usc.edu Subject: Possible include file bug? When reporting the OSF/1 bug that I compensated for in my recent patch, I was told that perhaps this isn't a bug. Upon reflection, this may be right. In src/child.c, we see: #if defined(_POSIX_SOURCE) #include #endif /* HAVE_SELECT */ However, removing these lines has no effect (under OSF/1, anyhow)... the program still compiles. Further, the man page for select sez: SYNOPSIS #include #include int select( int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) ; Note that it does _NOT_ say to include . Further, looking at the text in implies that would never be necessary unless one is running a parallel version of unix. Mike, what was the motivation for inserting it in the first place? Thanks, Dan From rdist-dev-request@usc.edu Wed Mar 16 15:52:12 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15044; Wed, 16 Mar 94 15:52:14 PST Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15040; Wed, 16 Mar 94 15:52:12 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id PAA15273; Wed, 16 Mar 1994 15:50:35 -0800 Sender: "Michael A. Cooper" Date: Wed, 16 Mar 94 15:50:34 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: Dan Mosedale Cc: rdist-dev@usc.edu Subject: Re: Possible include file bug? In-Reply-To: Your message of Wed, 16 Mar 1994 15:25:55 -0800 Message-Id: > > When reporting the OSF/1 bug that I compensated for in my recent patch, I was > told that perhaps this isn't a bug. Upon reflection, this may be right. > In src/child.c, we see: > > #if defined(_POSIX_SOURCE) > #include > #endif /* HAVE_SELECT */ > > However, removing these lines has no effect (under OSF/1, anyhow)... the program > still compiles. Further, the man page for select sez: > > SYNOPSIS > > #include > #include > int select( > int nfds, > fd_set *readfds, > fd_set *writefds, > fd_set *exceptfds, > struct timeval *timeout) ; > > Note that it does _NOT_ say to include . Further, looking at > the text in implies that would never be > necessary unless one is running a parallel version of unix. > > Mike, what was the motivation for inserting it in the first place? > > Thanks, > Dan > It looks like only AIX need . I've modified src/child.c to look like: #include "defs.h" #include #include #if defined(NEED_SYS_SELECT_H) #include #endif /* NEED_SYS_SELECT_H */ and in config/os-aix3.h defined NEED_SYS_SELECT_H. mike From rdist-dev-request@usc.edu Fri Mar 18 13:34:05 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20961; Fri, 18 Mar 94 13:34:14 PST Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20957; Fri, 18 Mar 94 13:34:05 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0phmB8-0002fOC; Fri, 18 Mar 94 16:34 EST Message-Id: Date: Fri, 18 Mar 94 16:34 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Minor nit Is it my imagination, or have the log messages for removing stuff disappeared? If you use -oremove I think you used to see log entries for things removed, but now I don't. From rdist-dev-request@usc.edu Fri Mar 18 14:13:43 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23132; Fri, 18 Mar 94 14:13:51 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23118; Fri, 18 Mar 94 14:13:43 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id OAA16209; Fri, 18 Mar 1994 14:13:35 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA22975; Fri, 18 Mar 1994 14:11:06 -0800 Message-Id: <199403182211.OAA22975@dbeusee.us.oracle.com> Date: Fri, 18 Mar 1994 14:11:06 -0800 From: Don Beusee To: neal@ctd.comsat.com, rdist-dev@usc.edu Subject: Re: Minor nit I still see those, definately. From rdist-dev-request@usc.edu Fri Mar 18 13:58:53 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id NAA22788 for ; Fri, 18 Mar 1994 13:58:53 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id OAA14830; Fri, 18 Mar 1994 14:01:14 -0800 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20961; Fri, 18 Mar 94 13:34:14 PST Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20957; Fri, 18 Mar 94 13:34:05 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0phmB8-0002fOC; Fri, 18 Mar 94 16:34 EST Message-Id: Date: Fri, 18 Mar 94 16:34 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Minor nit Status: R Is it my imagination, or have the log messages for removing stuff disappeared? If you use -oremove I think you used to see log entries for things removed, but now I don't. From rdist-dev-request@usc.edu Fri Mar 18 17:38:12 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03269; Fri, 18 Mar 94 17:38:23 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03227; Fri, 18 Mar 94 17:38:12 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id RAA00670; Fri, 18 Mar 1994 17:38:10 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id RAA26025; Fri, 18 Mar 1994 17:35:42 -0800 Message-Id: <199403190135.RAA26025@dbeusee.us.oracle.com> Date: Fri, 18 Mar 1994 17:35:42 -0800 From: Don Beusee To: mcooper@usc.edu Subject: rdist & rdistd Cc: rdist-dev@usc.edu Now that rdist is not setuid, why not combine the programs back together into one executable? Regards, Don. From rdist-dev-request@usc.edu Mon Mar 21 06:03:11 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24202; Mon, 21 Mar 94 06:03:15 PST Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA24198; Mon, 21 Mar 94 06:03:11 PST Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29) id m0pikZS-0002fOC; Mon, 21 Mar 94 09:03 EST Message-Id: Date: Mon, 21 Mar 94 09:03 EST From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: rdist for linux When I mentioned linux here before Michael A. Cooper said he had received patches. But being impatient (and bored) I went ahead and made a patch. Linux is pretty easy, it's almost identical to hpux. Michael, even though you already have a patch you might find something useful here anyway. This compiles cleanly and has been lightly tested. A couple of #ifndef linux's were used in the source files - these are not linux's fault. *** ./src/child.c-dist Mon Feb 7 16:00:38 1994 --- ./src/child.c Sat Mar 19 15:23:53 1994 *************** *** 51,58 **** #include #if defined(_POSIX_SOURCE) #include ! #endif /* HAVE_SELECT */ typedef enum _PROCSTATE { PSrunning, --- 51,62 ---- #include #if defined(_POSIX_SOURCE) + #ifdef LINUX + #include + #else #include ! #endif /* LINUX */ ! #endif /* _POSIX_SOURCE */ typedef enum _PROCSTATE { PSrunning, *** ./config/os-linux.h-dist Sat Mar 19 15:40:18 1994 --- ./config/os-linux.h Sat Mar 19 15:46:23 1994 *************** *** 0 **** --- 1,151 ---- + /* + * Copyright (c) 1993 Michael A. Cooper + * Copyright (c) 1993 Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + + /* + * $Id: os-hpux.h,v 6.12 1994/02/24 01:56:17 mcooper Exp mcooper $ + * @(#)os-hpux.h + */ + + /* + * LINUX + */ + + /* + * Define the following name for use in #ifdef's. + * The value should be all upper-case with no periods (.). + */ + #if !defined(LINUX) + #define LINUX + #endif + + /* + * We need + */ + #define NEED_UTIME_H + + /* + * Set process args to messages that show up when running ps(1) + * + * Under some OS's, the SETARGS code will cause ": is not an identifier" + * errors for "special" commands. + */ + #define SETARGS + + /* + * Define the type of directory routines your system has. + */ + #define DIR_TYPE DIR_DIRENT + + /* + * Determine what routines we have to get filesystem info. + */ + #define FSI_TYPE FSI_GETMNTENT + + /* + * Type of non-blocking I/O. + */ + #define NBIO_TYPE NBIO_FCNTL + + /* + * Type of wait() function to use. + */ + #define WAIT_TYPE WAIT_WAITPID + + /* + * Type of argument passed to wait() (above). + */ + #define WAIT_ARG_TYPE int + + /* + * Select the type of executable file format. + */ + /* #define EXE_TYPE EXE_HPEXEC */ + + /* + * Select the type of statfs() system call (if any). + */ + #define STATFS_TYPE STATFS_BSD + + /* + * Type of arg functions we have. + */ + #define ARG_TYPE ARG_STDARG + + /* + * Do we have select()? + */ + #define HAVE_SELECT + + #define POSIX_SIGNALS + + /* + * UID argument type for chown() + */ + typedef uid_t CHOWN_UID_T; + + /* + * GID argument type for chown() + */ + typedef gid_t CHOWN_GID_T; + + /* + * Our types, usually these are uid_t and gid_t. + */ + typedef uid_t UID_T; /* Must be signed */ + typedef gid_t GID_T; /* Must be signed */ + + /* + * Generic pointer, used by memcpy, malloc, etc. Usually char or void. + */ + typedef void POINTER; + + /* + * Type of set file time function available + */ + #define SETFTIME_TYPE SETFTIME_UTIME + + /* + * We have fchown() + */ + #define HAVE_FCHOWN + + /* + * We have fchmod() + */ + #define HAVE_FCHMOD + + /* + * Path to remote shell command + */ + #define _PATH_REMSH "/usr/bin/rsh" *** ./config/mf.linux-dist Sat Mar 19 15:40:36 1994 --- ./config/mf.linux Sat Mar 19 14:57:12 1994 *************** *** 0 **** --- 1,55 ---- + # + # Copyright (c) 1993 Michael A. Cooper + # Copyright (c) 1993 Regents of the University of California. + # All rights reserved. + # + # Redistribution and use in source and binary forms, with or without + # modification, are permitted provided that the following conditions + # are met: + # 1. Redistributions of source code must retain the above copyright + # notice, this list of conditions and the following disclaimer. + # 2. Redistributions in binary form must reproduce the above copyright + # notice, this list of conditions and the following disclaimer in the + # documentation and/or other materials provided with the distribution. + # 3. All advertising materials mentioning features or use of this software + # must display the following acknowledgement: + # This product includes software developed by the University of + # California, Berkeley and its contributors. + # 4. Neither the name of the University nor the names of its contributors + # may be used to endorse or promote products derived from this software + # without specific prior written permission. + # + # THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + # ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + # SUCH DAMAGE. + # + # $Id: mf.TEMPLATE,v 6.3 1993/07/15 19:58:48 mcooper Exp mcooper $ + # + + # + # linux Makefile + # + + # + # Functions that are missing in this OS are contained in the + # files specified in ${MISSINGOBJS}. + # + #MISSINGOBJS = $(O)strerror.o $(O)strcasecmp.o + + # + # System libraries that we need to load. + # + #LIB_SYS = -lPW + + # + # System dependent options for compiling + # + CFLAGS_OS = -D_POSIX_SOURCE -O2 *** ./config/os-type-dist Fri Feb 25 17:54:23 1994 --- ./config/os-type Sat Mar 19 11:33:01 1994 *************** *** 74,79 **** --- 74,80 ---- *" dcosx "*) OS=dcosx;; *"cx/ux"*) OS=cxux;; *"hp-ux"*) OS=hpux;; + *"linux"*) OS=linux;; esac fi *** ./include/defs.h-dist Thu Mar 3 19:03:42 1994 --- ./include/defs.h Sat Mar 19 15:29:55 1994 *************** *** 46,54 **** --- 46,56 ---- * These are not defined for POSIX, but required * by a number of system header files. */ + #ifndef linux typedef unsigned short ushort; typedef unsigned short u_short; typedef unsigned long u_long; + #endif #endif From rdist-dev-request@usc.edu Mon Mar 21 06:34:09 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AB25289; Mon, 21 Mar 94 06:35:10 PST Return-Path: Received: from mail.swip.net by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25260; Mon, 21 Mar 94 06:34:09 PST Received: by mail.swip.net (8.6.8/2.01) id PAA16705; Mon, 21 Mar 1994 15:33:47 +0100 Received: from cricket by nike.volvo.se with SMTP (8.6.4/1.37) id PAA03991; Mon, 21 Mar 1994 15:32:54 +0100 Received: from eagle.vd.volvo.se by cricket with SMTP id AA00815 (5.65c8/IDA-1.4.3 for rdist-dev@usc.edu); Mon, 21 Mar 1994 15:27:22 +0100 Received: by eagle.vd.volvo.se (AIX 3.2/UCB 5.64/4.03) id AA42607; Mon, 21 Mar 1994 15:32:38 +0100 From: v015231@eagle.vd.volvo.se (Kjell Johansson) Message-Id: <9403211432.AA42607@eagle.vd.volvo.se> Subject: Development rdist ? To: rdist-dev@usc.edu Date: Mon, 21 Mar 94 15:32:36 CUT X-Fax: +46 31 542841 Return-Receipt-To: Kjell_Johansson@vd.volvo.se X-Mailer: ELM [version 2.3 PL11] X-Charset: LATIN1 X-Char-Esc: 29 Hello ! I am a user of rdist and have now tested the 6.1.3-beta version. It works fine but i would need som minor changes/developments to be quite happy. I now wonder if there are any MORE who would like to see this development. I try to use rdist and use as few distfiles as possible, so i want to be able to 'externalize'/automate as much as possible, for example by using -d option to rdist, generate rdist commands from scripts, generate distfiles and so on. 1. Usage of cmdspecial. When using cmdspecial there is no way to use distfile variables because the whole string is sent without any variable substitutions performed. I understand variables that are environmentvariables in the target machine are substituted when they are executed there, but there are not many environment variables defined there, eh ??? Is there any interest in making a function, or flag to cmdspecial, that makes it possible to use distfilevariables in cmdspecial commands, and have them substituted before the command is sent to the target host for execution ?? 2. LOCAL ERROR: Error in distfile: line x: variable_name redefined If i have a distfile that uses the same variable, i get this FATAL message. I would like to have it NON-FATAL, i. e. only as a warning. The same problem exists when using -d option with the same variable in rdist command. 3. Anyone who would like to see a distfile-''special'' command executed BEFORE a file is updated or installed. 4. Anyone who have information about what is in the development plans for rdist in 1-2 years time ? Anyone interest for development of functions 1-3 ??? Regards Kjell Johansson From rdist-dev-request@usc.edu Mon Mar 21 08:10:13 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29097; Mon, 21 Mar 94 08:10:15 PST Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29090; Mon, 21 Mar 94 08:10:13 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA09215 (5.67a/IDA-1.5+AMD for ); Mon, 21 Mar 1994 08:10:13 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA22253 (5.67a/IDA-1.5+AMD for ); Mon, 21 Mar 1994 08:10:12 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA28393; Mon, 21 Mar 94 10:07:57 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA28562; Mon, 21 Mar 94 10:10:29 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 21 Mar 1994 10:10:29 -0600 (CST) Message-Id: Date: Mon, 21 Mar 1994 10:10:29 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu Subject: undetected typo I'm running 6.1.b3 (unpatched at the moment) on SunOS 4.1.[123] and HP 9000s700/9.01 machines, initiated from the former. My dist was attempting to push files to a host called {, and I was suspecting core leaks and other scary things. I ended up finding that I'd done the following: snm: ( /usr/local/lib/snm ) -> ( {${SNM}) install; snl: ( /usr/local/lib/snl ) -> ( {${SNL}) install; Rdist was taking the extraneous { to be a hostname. Stupid mistake on my part, but I'm real suprised that it passed the syntax check. From rdist-dev-request@usc.edu Mon Mar 21 13:56:37 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18144; Mon, 21 Mar 94 13:56:38 PST Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18140; Mon, 21 Mar 94 13:56:37 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id NAA07736; Mon, 21 Mar 1994 13:56:34 -0800 Sender: "Michael A. Cooper" Date: Mon, 21 Mar 94 13:56:33 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: Don Beusee Cc: rdist-dev@usc.edu Subject: Re: rdist & rdistd In-Reply-To: Your message of Fri, 18 Mar 1994 17:35:42 -0800 Message-Id: > Now that rdist is not setuid, why not combine the programs back together > into one executable? > > Regards, > Don. > > You can still run rdist setuid, and you must, if you don't have remote shell. mike From rdist-dev-request@usc.edu Mon Mar 21 14:42:30 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20790; Mon, 21 Mar 94 14:42:32 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20786; Mon, 21 Mar 94 14:42:30 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id OAA08544; Mon, 21 Mar 1994 14:42:22 -0800 Received: from localhost (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.5/37.7) id OAA08123; Mon, 21 Mar 1994 14:39:51 -0800 Message-Id: <199403212239.OAA08123@dbeusee.us.oracle.com> Date: Mon, 21 Mar 1994 14:39:51 -0800 From: Don Beusee To: rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? using m4 with rdist does most of the things you want. I am using that to use variables in special/cmdspecial commands. It works great! I have a central rdist.sh script which knows about "packages" and it centrally stores the location of all distfiles and how to invoke rdist for that package. I have another central file which is a table of hosts and packages. The flat file table controls what packages are rdist'd where. The script gets a list of hosts from the flat file table and makes a -d "HOSTS=($hosts)" This is a simplified explaination of what I've done with rdist. But it works very well. Before I came to the Data Center group, it was a nightmare to find distfiles for various files. I even have a -find option which shows which package to rdist in order to update a file. I think there is a prespecial planned for some future release. Regards, Don. From rdist-dev-request@usc.edu Mon Mar 21 07:05:22 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.5/37.7) with ESMTP id HAA03340 for ; Mon, 21 Mar 1994 07:05:22 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id HAA28902; Mon, 21 Mar 1994 07:07:48 -0800 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AB25289; Mon, 21 Mar 94 06:35:10 PST Received: from mail.swip.net by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25260; Mon, 21 Mar 94 06:34:09 PST Received: by mail.swip.net (8.6.8/2.01) id PAA16705; Mon, 21 Mar 1994 15:33:47 +0100 Received: from cricket by nike.volvo.se with SMTP (8.6.4/1.37) id PAA03991; Mon, 21 Mar 1994 15:32:54 +0100 Received: from eagle.vd.volvo.se by cricket with SMTP id AA00815 (5.65c8/IDA-1.4.3 for rdist-dev@usc.edu); Mon, 21 Mar 1994 15:27:22 +0100 Received: by eagle.vd.volvo.se (AIX 3.2/UCB 5.64/4.03) id AA42607; Mon, 21 Mar 1994 15:32:38 +0100 From: v015231@eagle.vd.volvo.se (Kjell Johansson) Message-Id: <9403211432.AA42607@eagle.vd.volvo.se> Subject: Development rdist ? To: rdist-dev@usc.edu Date: Mon, 21 Mar 94 15:32:36 CUT X-Fax: +46 31 542841 Return-Receipt-To: Kjell_Johansson@vd.volvo.se X-Mailer: ELM [version 2.3 PL11] X-Charset: LATIN1 X-Char-Esc: 29 Status: R Hello ! I am a user of rdist and have now tested the 6.1.3-beta version. It works fine but i would need som minor changes/developments to be quite happy. I now wonder if there are any MORE who would like to see this development. I try to use rdist and use as few distfiles as possible, so i want to be able to 'externalize'/automate as much as possible, for example by using -d option to rdist, generate rdist commands from scripts, generate distfiles and so on. 1. Usage of cmdspecial. When using cmdspecial there is no way to use distfile variables because the whole string is sent without any variable substitutions performed. I understand variables that are environmentvariables in the target machine are substituted when they are executed there, but there are not many environment variables defined there, eh ??? Is there any interest in making a function, or flag to cmdspecial, that makes it possible to use distfilevariables in cmdspecial commands, and have them substituted before the command is sent to the target host for execution ?? 2. LOCAL ERROR: Error in distfile: line x: variable_name redefined If i have a distfile that uses the same variable, i get this FATAL message. I would like to have it NON-FATAL, i. e. only as a warning. The same problem exists when using -d option with the same variable in rdist command. 3. Anyone who would like to see a distfile-''special'' command executed BEFORE a file is updated or installed. 4. Anyone who have information about what is in the development plans for rdist in 1-2 years time ? Anyone interest for development of functions 1-3 ??? Regards Kjell Johansson From rdist-dev-request@usc.edu Mon Mar 21 14:47:06 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21284; Mon, 21 Mar 94 14:49:31 PST Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21071; Mon, 21 Mar 94 14:47:06 PST Received: from localhost (mcooper@localhost) by acamar.usc.edu (8.6.4/8.6.4) id OAA08208 for real-rdist-announce@usc.edu; Mon, 21 Mar 1994 14:47:05 -0800 Sender: "Michael A. Cooper" Date: Mon, 21 Mar 94 14:47:04 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu Subject: Rdist 6.1beta.4 released To: real-rdist-announce@usc.edu Message-Id: Rdist version 6.1beta.4 is now available for anonymous ftp from usc.edu under /pub/rdist. It consists mostly of bug fixes and a new platform port or two since 5.1. See "ChangeLog" for more info. mike From rdist-dev-request@usc.edu Tue Mar 22 07:29:40 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04661; Tue, 22 Mar 94 07:29:44 PST Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04602; Tue, 22 Mar 94 07:29:40 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02952 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 07:29:29 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA20998 (5.67a/IDA-1.5+AMD); Tue, 22 Mar 1994 07:29:28 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA02538; Tue, 22 Mar 94 09:29:27 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA17077; Tue, 22 Mar 94 09:29:46 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 09:29:46 -0600 (CST) Message-Id: Date: Tue, 22 Mar 1994 09:29:46 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? In-Reply-To: <199403212239.OAA08123@dbeusee.us.oracle.com> References: <199403212239.OAA08123@dbeusee.us.oracle.com> >I have a central rdist.sh script which knows about "packages" and it centrally >stores the location of all distfiles and how to invoke rdist for that package. >I have another central file which is a table of hosts and packages. The flat >file table controls what packages are rdist'd where. I do kinda the same thing, but differently. I have a file that lists attributes and package names for each host. A Perl script sucks this in and spits out rdist macros, which are prepended to a file containing the rules to create the Distfile. >using m4 with rdist does most of the things you want. Be careful, though -- all of the vendor-supplied m4's that I've worked with have broken on relatively small files. GNU m4 works well for me. >--=8======================================================================--- From rdist-dev-request@usc.edu Tue Mar 22 09:14:40 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09208; Tue, 22 Mar 94 09:14:46 PST Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09203; Tue, 22 Mar 94 09:14:40 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id JAA07929; Tue, 22 Mar 1994 09:12:18 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA19271; Tue, 22 Mar 94 09:11:42 PST Message-Id: <9403221711.AA19271@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Tue, 22 Mar 1994 09:11:46 -0800 In-Reply-To: "Anthony D'atri" "Re: Development rdist ?" (Mar 22, 9:29) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Anthony D'atri" , rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? On Mar 22, 9:29, "Anthony D'atri" wrote: } Subject: Re: Development rdist ? > >I have a central rdist.sh script which knows about "packages" and it centrally > >stores the location of all distfiles and how to invoke rdist for that package. > >I have another central file which is a table of hosts and packages. The flat > >file table controls what packages are rdist'd where. > > I do kinda the same thing, but differently. I have a file that lists > attributes and package names for each host. A Perl script sucks this in > and spits out rdist macros, which are prepended to a file containing the > rules to create the Distfile. Am I the only person who thinks this is just a bit ridiculous? I always thought that the Distfile should be the control file for rdist. Why multiply them? It's getting difficult these days, with so much of the functionality of rdist only available on the command line, but I think that's a problem that should be solved by putting that functionality back into the Distfiles. Is this *really* the direction we want to go with rdist? Multiple Distfiles, control files that locate the Distfiles, other files with tables of hosts & packages, etc.? Why can't we have one (1) control file for rdist? -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From rdist-dev-request@usc.edu Tue Mar 22 11:34:50 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16544; Tue, 22 Mar 94 11:34:58 PST Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16538; Tue, 22 Mar 94 11:34:50 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA17963 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 11:33:29 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA29050 (5.67a/IDA-1.5+AMD); Tue, 22 Mar 1994 11:33:27 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA01297; Tue, 22 Mar 94 13:33:25 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA17642; Tue, 22 Mar 94 13:33:44 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 13:33:43 -0600 (CST) Message-Id: Date: Tue, 22 Mar 1994 13:33:43 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, v015231@eagle.vd.volvo.se, stssram@st.unocal.com (Bob Myers) Subject: Re: Development rdist ? In-Reply-To: <9403221711.AA19271@st.unocal.com> References: <9403221711.AA19271@st.unocal.com> >Why can't we have one (1) control file for rdist? My file does not only contain information for rdist. >Is this *really* the direction we want to go with rdist? Multiple >Distfiles, control files that locate the Distfiles, other files with tables >of hosts & packages, etc.? The current Distfile language isn't really up to my needs, and I'm kinda loathe to have day-to-day edits of that kind of syntax rather than a plain tabular file like I use. Expanding the set operators to be arbitrarily nestable would handle some of my needs, though. Other things wouldn't seem to easily integrate. For example, I have a global syslog.conf file that gets post-processed after disting, interpolating values in my central configuration file. >--=8======================================================================--- From rdist-dev-request@usc.edu Tue Mar 22 13:36:24 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22569; Tue, 22 Mar 94 13:36:25 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22565; Tue, 22 Mar 94 13:36:24 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id NAA04602; Tue, 22 Mar 1994 13:36:03 -0800 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id NAA22960; Tue, 22 Mar 1994 13:33:30 -0800 Message-Id: <199403222133.NAA22960@dbeusee.us.oracle.com> Date: Tue, 22 Mar 1994 13:33:30 -0800 From: Don Beusee To: aad@lovecraft.amd.com, rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? Thats what I'm using, GNU m4. Vendor m4 does not work with distfiles very well due to quoting problems. From rdist-dev-request@usc.edu Tue Mar 22 08:07:07 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id IAA20009 for ; Tue, 22 Mar 1994 08:07:07 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id IAA07579; Tue, 22 Mar 1994 08:09:24 -0800 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04661; Tue, 22 Mar 94 07:29:44 PST Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA04602; Tue, 22 Mar 94 07:29:40 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02952 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 07:29:29 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA20998 (5.67a/IDA-1.5+AMD); Tue, 22 Mar 1994 07:29:28 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA02538; Tue, 22 Mar 94 09:29:27 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA17077; Tue, 22 Mar 94 09:29:46 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 09:29:46 -0600 (CST) Message-Id: Date: Tue, 22 Mar 1994 09:29:46 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? In-Reply-To: <199403212239.OAA08123@dbeusee.us.oracle.com> References: <199403212239.OAA08123@dbeusee.us.oracle.com> Status: R >I have a central rdist.sh script which knows about "packages" and it centrally >stores the location of all distfiles and how to invoke rdist for that package. >I have another central file which is a table of hosts and packages. The flat >file table controls what packages are rdist'd where. I do kinda the same thing, but differently. I have a file that lists attributes and package names for each host. A Perl script sucks this in and spits out rdist macros, which are prepended to a file containing the rules to create the Distfile. >using m4 with rdist does most of the things you want. Be careful, though -- all of the vendor-supplied m4's that I've worked with have broken on relatively small files. GNU m4 works well for me. >--=8======================================================================--- From rdist-dev-request@usc.edu Tue Mar 22 13:52:59 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23315; Tue, 22 Mar 94 13:53:01 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA23307; Tue, 22 Mar 94 13:52:59 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id NAA05777; Tue, 22 Mar 1994 13:52:44 -0800 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id NAA23199; Tue, 22 Mar 1994 13:50:11 -0800 Message-Id: <199403222150.NAA23199@dbeusee.us.oracle.com> Date: Tue, 22 Mar 1994 13:50:11 -0800 From: Don Beusee To: aad@lovecraft.amd.com, rdist-dev@usc.edu, stssram@st.unocal.com, v015231@eagle.vd.volvo.se Subject: Re: Development rdist ? Also consider that some packages require others to be rdist'd first. A single flat distfile model does not work with dependencies... If it were more like make, then maybe... From rdist-dev-request@usc.edu Tue Mar 22 12:18:48 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id MAA22200 for ; Tue, 22 Mar 1994 12:18:48 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id MAA28260; Tue, 22 Mar 1994 12:21:15 -0800 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16544; Tue, 22 Mar 94 11:34:58 PST Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA16538; Tue, 22 Mar 94 11:34:50 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA17963 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 11:33:29 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA29050 (5.67a/IDA-1.5+AMD); Tue, 22 Mar 1994 11:33:27 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA01297; Tue, 22 Mar 94 13:33:25 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA17642; Tue, 22 Mar 94 13:33:44 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 13:33:43 -0600 (CST) Message-Id: Date: Tue, 22 Mar 1994 13:33:43 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, v015231@eagle.vd.volvo.se, stssram@st.unocal.com (Bob Myers) Subject: Re: Development rdist ? In-Reply-To: <9403221711.AA19271@st.unocal.com> References: <9403221711.AA19271@st.unocal.com> Status: R >Why can't we have one (1) control file for rdist? My file does not only contain information for rdist. >Is this *really* the direction we want to go with rdist? Multiple >Distfiles, control files that locate the Distfiles, other files with tables >of hosts & packages, etc.? The current Distfile language isn't really up to my needs, and I'm kinda loathe to have day-to-day edits of that kind of syntax rather than a plain tabular file like I use. Expanding the set operators to be arbitrarily nestable would handle some of my needs, though. Other things wouldn't seem to easily integrate. For example, I have a global syslog.conf file that gets post-processed after disting, interpolating values in my central configuration file. >--=8======================================================================--- From rdist-dev-request@usc.edu Tue Mar 22 15:03:56 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26863; Tue, 22 Mar 94 15:04:01 PST Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26856; Tue, 22 Mar 94 15:03:56 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02998 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 15:02:55 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA05578 (5.67a/IDA-1.5+AMD); Tue, 22 Mar 1994 15:02:53 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA14957; Tue, 22 Mar 94 17:02:52 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA18273; Tue, 22 Mar 94 17:03:12 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 17:03:11 -0600 (CST) Message-Id: <4hXrYjaXhG4BAzCSYO@lovecraft.amd.com> Date: Tue, 22 Mar 1994 17:03:11 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rdist-dev@usc.edu, stssram@st.unocal.com, v015231@eagle.vd.volvo.se, Don Beusee Subject: Re: Development rdist ? In-Reply-To: <199403222150.NAA23199@dbeusee.us.oracle.com> References: <199403222150.NAA23199@dbeusee.us.oracle.com> >Also consider that some packages require others to be rdist'd first. A single >flat distfile model does not work with dependencies... While I do wish that rdist had make-like dependency stuff, it's true that the packages/targets in a Distfile get processed in sequence, so depended-on stuff can be placed first. I've had occasional hassles where something disted to one host relied on another file already being disted to another -- eg., a machine NFS-mounts /usr/local, and I dist a Perl script to it that gets run by a special(). Perl itself needs to be on the /usr/local server first. >--=8======================================================================--- From rdist-dev-request@usc.edu Tue Mar 22 16:22:15 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01164; Tue, 22 Mar 94 16:22:18 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01160; Tue, 22 Mar 94 16:22:15 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id QAA17620; Tue, 22 Mar 1994 16:22:15 -0800 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id QAA24660; Tue, 22 Mar 1994 16:19:42 -0800 Message-Id: <199403230019.QAA24660@dbeusee.us.oracle.com> Date: Tue, 22 Mar 1994 16:19:42 -0800 From: Don Beusee To: aad@lovecraft.amd.com Subject: Re: Development rdist ? Cc: rdist-dev@usc.edu Yes. Works great for including other distfiles and using variables in special commands. From Anthony.Datri@amd.com Tue Mar 22 16:09:17 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id QAA24556 for ; Tue, 22 Mar 1994 16:09:16 -0800 Received: from amdext.amd.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id QAA16855; Tue, 22 Mar 1994 16:11:47 -0800 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA07965 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 16:11:40 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA07812 (5.67a/IDA-1.5+AMD for ); Tue, 22 Mar 1994 16:11:37 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA18704; Tue, 22 Mar 94 18:11:35 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA18591; Tue, 22 Mar 94 18:11:54 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Tue, 22 Mar 1994 18:11:53 -0600 (CST) Message-Id: Date: Tue, 22 Mar 1994 18:11:53 -0600 (CST) From: "Anthony D'atri" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Don Beusee Subject: Re: Development rdist ? In-Reply-To: <199403222349.PAA24367@dbeusee.us.oracle.com> References: <199403222349.PAA24367@dbeusee.us.oracle.com> Status: R Those look like something that might show up in sendmail.cf ... Oh -- you're m4ing distfiles themselves? >--=8======================================================================--- From rdist-dev-request@usc.edu Wed Mar 23 14:00:04 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17906; Wed, 23 Mar 94 14:00:22 PST Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17899; Wed, 23 Mar 94 14:00:04 PST Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id NAA15201; Wed, 23 Mar 1994 13:52:09 -0800 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA08575; Wed, 23 Mar 94 13:54:52 PST Message-Id: <9403232154.AA08575@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Wed, 23 Mar 1994 13:56:56 -0800 In-Reply-To: Don Beusee "Re: Development rdist ?" (Mar 22, 13:50) Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Don Beusee , aad@lovecraft.amd.com, rdist-dev@usc.edu, v015231@eagle.vd.volvo.se Subject: Towards Rdist Version 7? On Mar 22, 13:33, Anthony D'atri wrote: } Subject: Re: Development rdist ? > > >Why can't we have one (1) control file for rdist? > > My file does not only contain information for rdist. Oh, ok. I've done similar things myself. For example, we use the NIS (Yellow Pages) "netgroup" database for a lot of tools here to do things to all the machines in a netgroup instead of for a single host. We have "nrsh", similar to "rsh", to run commands on all machines in a netgroup, for example. I wrote "nrdist", a preprocessor for Distfiles that replaces netgroup names with the hosts in the netgroup, and then feeds the results to "classic" rdist. That way we only need to maintain the list of machines in one place, the NIS database, for lots of different sorts of tools. > >Is this *really* the direction we want to go with rdist? Multiple > >Distfiles, control files that locate the Distfiles, other files with tables > >of hosts & packages, etc.? > > The current Distfile language isn't really up to my needs, and I'm kinda > loathe to have day-to-day edits of that kind of syntax rather than a > plain tabular file like I use. I entirely agree that the current Distfile language is inadequate. Given the current language, we do need multiple control files to give the kind of control many of us need. But I think we should consider extending the Distfile language itself. It would be nice if we could provide standard methods of doing the sorts of things everyone uses custom solutions for, like dependencies, extra variable substitution, etc. This is, I know, a fairly large change, but I think it would be a good idea. > Expanding the set operators to be arbitrarily nestable would handle some > of my needs, though. I'm not entirely sure what the trouble is here. I'm guessing it's a syntax problem, in that you don't like using temporary variables in the construction of lists? > Other things wouldn't seem to easily integrate. > For example, I have a global syslog.conf file that gets post-processed > after disting, interpolating values in my central configuration file. I agree this sort of thing doesn't integrate very well into rdist as such. How do you handle this now? Do you have a preprocessor or command line defines to rdist to create custom "cmdspecial" or "special" commands for each host? When I've had to do this, I've tended to rdist the configuration file and a shell-script to post-process the file, as well as the file itself, and run the shell-script as a special command. I do this for rdist'ing rc.local and root crontabs, for example. I admit I've not been completely happy with this solution. On Mar 22, 13:50, Don Beusee wrote: } Subject: Re: Development rdist ? > Also consider that some packages require others to be rdist'd first. A single > flat distfile model does not work with dependencies... > > If it were more like make, then maybe... I would like dependencies, too, but I'm a little afraid of building full-fledged "make" dependency checking into rdist... hmmm. Anyway, I'd like to build a wish-list for rdist-7 language features. This is what I'd like to see: 1) Host-specific options, rather than package-specific. I want some way of specifying certain options on a per-host basis, rather than per-package, in the Distfile. I really want timeout values settable this way. Probably compression, logging, and rdistd path would be nice too. 2) Some sort of simple dependency checking. 3) Some kind of conditional behavior, based on the state of the remote (client) machine. Maybe be able to run a command on the remote machine, and have rdist behavior change as a result of the output of that command. Example: rdist'ing different versions of a file to different machine architecture/OS versions, without bothering to keep track on the server which machine has what architecture or OS level. But perhaps this would be easiest to handle (and provide the most flexible behavior) with a "prespecial" command that was executed before rdist'ing a file, followed by "special" commands afterwards. 4) Logging options should be settable in the Distfile as well as on the command line, on both a per-host and a per-package basis. 5) Other options should be available on a per-package basis in the Distfile, such as minimum free inodes/files. 6) Certain global options should be available, like number of child rdist processes, rsh-path. 7) I'd like a rdist-7 to continue to accept old rdist-6 Distfiles as much as possible. I expect new features to break rdist-6, of course. Comments? -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From rdist-dev-request@usc.edu Wed Mar 23 14:47:29 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20052; Wed, 23 Mar 94 14:47:32 PST Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20048; Wed, 23 Mar 94 14:47:29 PST Received: from amdint.amd.com by amdext.amd.com with SMTP id AA05593 (5.67a/IDA-1.5+AMD for ); Wed, 23 Mar 1994 14:46:15 -0800 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA04665 (5.67a/IDA-1.5+AMD); Wed, 23 Mar 1994 14:46:13 -0800 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA03919; Wed, 23 Mar 94 16:46:11 CST Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA22837; Wed, 23 Mar 94 16:46:31 CST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Wed, 23 Mar 1994 16:46:30 -0600 (CST) Message-Id: Date: Wed, 23 Mar 1994 16:46:30 -0600 (CST) From: Anthony D'atri Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Don Beusee , rdist-dev@usc.edu, v015231@eagle.vd.volvo.se, stssram@st.unocal.com (Bob Myers) Subject: Re: Towards Rdist Version 7? In-Reply-To: <9403232154.AA08575@st.unocal.com> References: <9403232154.AA08575@st.unocal.com> >We have "nrsh", similar to "rsh", to run commands on all machines in a netgroup, for >example. Perl comes with a gsh that reads a file very similar to what I use. I've been meaning to tweak it into working here. >> Expanding the set operators to be arbitrarily nestable would handle some >> of my needs, though. >I'm not entirely sure what the trouble is here. I'm guessing it's a syntax >problem, in that you don't like using temporary variables in the >construction of lists? It *is* kind of a hassle. >> For example, I have a global syslog.conf file that gets post-processed >> after disting, interpolating values in my central configuration file. >I agree this sort of thing doesn't integrate very well into rdist as such. >How do you handle this now? Okay, my config file (it's called "machines") contains a list of hosts with attributes. One attribute is "syslog", which means that that host should get /etc/syslog.conf disted to it. One host also has the attribute "defaultloghost", which means that the other hosts should forward syslog messages to it. A makefile runs a Perl script over this configuation file to create a list of macro definitions for rdist: SYSLOG = (somehost anotherhost) This list of macros is prepended by the makefile to a common set of package rules to create Distfile. Here's the package for syslog: # assumption: syslogd forks syslog: ( /usr/local/adm/etc/syslog.conf.global ) -> ( ${SYSLOG} ) install /etc/syslog.conf.global; special "/usr/adm/bin/transmogrify /etc/syslog.conf ; kill -HUP `cat /etc/syslog.pid` "; So, any host in "machines" gets the global file disted to it, and the special command runs a filter called transmogrify to process the global file into the real, local file. Transmogrify basically plucks some values out of "machines" (like the administrative domain, the loghost, and such), and runs the global file through gnum4 with definitions on the command-line like -DARCH=sun4 -DHOST=lovecraft -DLOGHOST=dvorak to create the local file (syslog.conf). Here are some snippets from syslog.conf.global: # HP has no 'news' facility (grumble) ifelse(ARCH,hp9000s700,[dnl *.debug;mail.warning;local4.warning;daemon.warning netlog ],[dnl *.debug;mail.warning;local4.warning;news.warning; netlog ])dnl ifelse(HOST,LOGHOST,[dnl local4.debug /usr/adm/log/sysdata local4.emerg /usr/adm/log/syserrs local7.debug /usr/adm/log/ciscolog ],[dnl *.err;auth.notice @LOGHOST lpr.debug;kern.debug @LOGHOST user.emerg @LOGHOST mail.crit @LOGHOST local3.warn @LOGHOST local4.debug @LOGHOST ])dnl I guess this might seem outrageously complex from what I've written here, but it's implemented to be *general* -- the same config file/filter mechanism can be used with all sorts of files, notably /etc/printcap, /etc/op.access, /etc/sendmail.cf, /etc/resolv.conf, /etc/inetd.conf, and so on. In fact, printcap distribution is what motivated this sort of scheme in the first place. Another feature is that the "transmogrify" localization script does things like automagically create log files for syslog and spool directories out of /etc/printcap. The idea is to retain as little unique state as possible solely in / or /usr -- you don't have to worry about backing those up. When you install a new machine, you can do a bare minimum to get the machine on the net -- eg., fixing the vendor's broken ifconfig invocation -- then run an rdist to it to set up most or all of what you need to make it work in your environment. Also part of the idea is that changes get automatically propagated. >I do this for >rdist'ing rc.local and root crontabs, for example. I admit I've not been >completely happy with this solution. One of the problems I have is that [GNU]m4 doesn't seem to have a "case" sort of directive. Crontabs require some special handling, since crons typically aren't too impressed by blank lines or 0-length files. Admittedly, this sort of scheme fits the distribution of printcaps much more cleanly than it does crontabs. >--=8======================================================================--- From rdist-dev-request@usc.edu Thu Mar 24 10:59:57 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03551; Thu, 24 Mar 94 10:59:59 PST Return-Path: Received: from paris.ics.uci.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03543; Thu, 24 Mar 94 10:59:57 PST Received: from binky.ics.uci.edu by paris.ics.uci.edu id aa12627; 24 Mar 94 10:59 PST To: rdist-dev@binky.ICS.UCI.EDU Subject: proposed patch to 6.1b4 Date: Thu, 24 Mar 1994 10:59:53 -0800 From: Scott Erickson Message-Id: <9403241059.aa12627@paris.ics.uci.edu> I'd like to suggest the following patch for 6.1b4: diff config/os-svr4.h.orig config/os-svr4.h 125c125 < #define bcopy(a,b,c) memcpy(b,a,c) --- > #define bcopy(a,b,c) memmove(b,a,c) Under SunOS 5, memcpy() is not guaranteed to handle overlapping strings the same way that bcopy() does. I don't know if this is necessarily the case for other SVR4 systems. I'd like to see comments on this. Perhaps this modification needs to be added only to the end of config/os-sunos5.h. /se University of California Irvine | 714/856-4035 Information and Computer Science Department | erickson@ics.uci.edu UNIX Support Group | From rdist-dev-request@usc.edu Fri Mar 25 04:35:23 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09580; Fri, 25 Mar 94 04:35:25 PST Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09574; Fri, 25 Mar 94 04:35:23 PST Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id EAA10259; Fri, 25 Mar 1994 04:35:16 -0800 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id EAA00533; Fri, 25 Mar 1994 04:32:40 -0800 Message-Id: <199403251232.EAA00533@dbeusee.us.oracle.com> Date: Fri, 25 Mar 1994 04:32:40 -0800 From: Don Beusee To: rdist-dev@usc.edu, sources@binky.ICS.UCI.EDU Subject: Re: proposed patch to 6.1b4 Personally, I don't think it matters, since non SVR4 ports will still use memcpy() (like SVR3 ports), so the code should not do any overlapping copies. It might turn out that memcpy() is more efficient (if it does not have to protect against overlapping)... From rdist-dev-request@usc.edu Thu Mar 24 12:22:04 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id MAA00997 for ; Thu, 24 Mar 1994 12:22:03 -0800 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id LAA05593; Thu, 24 Mar 1994 11:29:45 -0800 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03551; Thu, 24 Mar 94 10:59:59 PST Received: from paris.ics.uci.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03543; Thu, 24 Mar 94 10:59:57 PST Received: from binky.ics.uci.edu by paris.ics.uci.edu id aa12627; 24 Mar 94 10:59 PST To: rdist-dev@binky.ICS.UCI.EDU Subject: proposed patch to 6.1b4 Date: Thu, 24 Mar 1994 10:59:53 -0800 From: Scott Erickson Message-Id: <9403241059.aa12627@paris.ics.uci.edu> Status: RO I'd like to suggest the following patch for 6.1b4: diff config/os-svr4.h.orig config/os-svr4.h 125c125 < #define bcopy(a,b,c) memcpy(b,a,c) --- > #define bcopy(a,b,c) memmove(b,a,c) Under SunOS 5, memcpy() is not guaranteed to handle overlapping strings the same way that bcopy() does. I don't know if this is necessarily the case for other SVR4 systems. I'd like to see comments on this. Perhaps this modification needs to be added only to the end of config/os-sunos5.h. /se University of California Irvine | 714/856-4035 Information and Computer Science Department | erickson@ics.uci.edu UNIX Support Group | From rdist-dev-request@usc.edu Fri Mar 25 14:41:28 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00849; Fri, 25 Mar 94 14:54:55 PST Return-Path: Received: from mail.cs.tu-berlin.de by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA00367; Fri, 25 Mar 94 14:41:28 PST Received: from gargleblaster.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA07884 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Fri, 25 Mar 1994 12:14:42 +0100 From: Matthias Klose Received: (doko@localhost) by gargleblaster.cs.tu-berlin.de (8.6.7/8.6.6) id MAA15796; Fri, 25 Mar 1994 12:13:14 +0100 Date: Fri, 25 Mar 1994 12:13:14 +0100 Message-Id: <199403251113.MAA15796@gargleblaster.cs.tu-berlin.de> To: rdist-dev@usc.edu Subject: simple lists in distfiles Reply-To: doko@cs.tu-berlin.de I have a problem with simple lists. The first rule doesn't work; nothing gets installed. However the second (commented) does work. Am I missing something? ALL = (/usr/local/*) TO_DIST = (/usr/local/{bin,lib}) NOT_TO_DIST = ${ALL} - ${TO_DIST} ${ALL} -> (swtn1) except ${NOT_TO_DIST}; install -oremove /tmp; #${TO_DIST} -> (swtn1) # install -oremove /tmp; ---------------------------------------------------------------------- % ls -CF /usr/local README adm/ etc/ lib/ src/ X11/ bin/ include/ man/ tmp/ ---------------------------------------------------------------------- Running NeXTstep 3.2 Version 6.1beta.3 - Protocol Version 6, Release 6.1beta, Patch level 3 (hardlink patch applied) da: Current message logging config: da: stdout=change,info,notice,nerror,ferror,warning,verbose,all,debug da: file= da: syslog=,nerror,ferror,all da: notify=change,info,notice,nerror,ferror,warning,verbose,all da: makenl(/usr/local/*) da: lookup(ALL, 1, 7a39c) da: makenl(/usr/local/{bin,lib}) da: lookup(TO_DIST, 1, 7a3e4) da: makenl(${ALL}) da: makenl(${TO_DIST}) da: expand(7a420, 1) start, list = ( ${ALL} ) da: lookup(ALL, 0, 0) da: makenl(null) da: expand(7a43c, 1) start, list = ( ${TO_DIST} ) da: lookup(TO_DIST, 0, 0) da: makenl(null) da: makenl(/usr/local/*) da: lookup(NOT_TO_DIST, 1, 7a490) da: makenl(${ALL}) da: makenl(swtn1) da: makenl(${NOT_TO_DIST}) da: expand(7a50c, 7) start, list = ( ${NOT_TO_DIST} ) da: lookup(NOT_TO_DIST, 0, 0) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(/tmp) da: expand(7c690, 1) start, list = ( /tmp ) da: makenl(null) da: insert((null), 7a4bc, 7a4d4, 7a4e0) start, files = ( ${ALL} ) da: expand(7a4bc, 3) start, list = ( ${ALL} ) da: lookup(ALL, 0, 0) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: makenl(null) da: expand(7a4d4, 7) start, list = ( swtn1 ) da: makenl(null) da: addchild() start da: addchild() created 'swtn1' pid 7985 fd 3 (active=1) da: spawn() Forked child 7985 for host swtn1 active = 1 da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 92 bytes] swtn1: doarrow(7a518, swtn1, 7a4e0) start swtn1: makeconn(swtn1) swtn1: updating host swtn1 da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 51 bytes] swtn1: Created notify temp file '/tmp/rdist007985' da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 125 bytes] swtn1: local user = root remote user = root swtn1: Remote command = 'rdistd -S' swtn1: Remote shell command = '/usr/ucb/rsh' da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 95 bytes] swtn1: <<< Cmd = V (\126) Msg = "" swtn1: >>> Cmd = V (\126) Msg = "6" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 117 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: >>> Cmd = c (\143) Msg = "Hda" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 457 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: Debug files->n_next= 501028, destdir=1, ddir=1 swtn1: Debug sc->sc_name=7c69c, destdir=1, ddir=1 swtn1: install(src=/usr/local/README,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/README /tmp swtn1: install: target=/usr/local/README src=/usr/local/README rname=README dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 234 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(README, 10) swtn1: except(/usr/local/README) swtn1: install(src=/usr/local/X11,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/X11 /tmp da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 163 bytes] swtn1: install: target=/usr/local/X11 src=/usr/local/X11 rname=X11 dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 391 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(X11, 10) swtn1: except(/usr/local/X11) swtn1: install(src=/usr/local/adm,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/adm /tmp swtn1: install: target=/usr/local/adm src=/usr/local/adm rname=adm dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 391 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(adm, 10) swtn1: except(/usr/local/adm) swtn1: install(src=/usr/local/bin,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/bin /tmp swtn1: install: target=/usr/local/bin src=/usr/local/bin rname=bin dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 108 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(bin, 10) swtn1: except(/usr/local/bin) da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 283 bytes] swtn1: install(src=/usr/local/etc,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/etc /tmp swtn1: install: target=/usr/local/etc src=/usr/local/etc rname=etc dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 55 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 356 bytes] swtn1: sendit(etc, 10) swtn1: except(/usr/local/etc) swtn1: install(src=/usr/local/include,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/include /tmp swtn1: install: target=/usr/local/include src=/usr/local/include rname=include dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 333 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(include, 10) swtn1: except(/usr/local/include) swtn1: install(src=/usr/local/lib,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/lib /tmp swtn1: install: target=/usr/local/lib src=/usr/local/lib rname=lib dest='/tmp' destdir=1, ddir=1 da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 66 bytes] swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 391 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(lib, 10) swtn1: except(/usr/local/lib) swtn1: install(src=/usr/local/man,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/man /tmp swtn1: install: target=/usr/local/man src=/usr/local/man rname=man dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 391 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(man, 10) swtn1: except(/usr/local/man) swtn1: install(src=/usr/local/src,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/src /tmp swtn1: install: target=/usr/local/src src=/usr/local/src rname=src dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 228 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(src, 10) swtn1: except(/usr/local/src) swtn1: install(src=/usr/local/tmp,dest=/tmp,ddir=1,destdir=1,opts=16) start swtn1: install -oremove /usr/local/tmp /tmp da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 163 bytes] swtn1: install: target=/usr/local/tmp src=/usr/local/tmp rname=tmp dest='/tmp' destdir=1, ddir=1 swtn1: >>> Cmd = T (\124) Msg = "20 /tmp" swtn1: response() start da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: waitup() select returned 1 activechildren = 1 da: [readchild(swtn1, 7985, 3) start] da: [readchild(swtn1, 7985, 3) got 203 bytes] swtn1: <<< Cmd =  (\005) Msg = "" swtn1: received ACK swtn1: sendit(tmp, 10) swtn1: except(/usr/local/tmp) swtn1: updating of swtn1 finished swtn1: closeconn() called swtn1: >>> Cmd =  (\002) Msg = "" da: [readchild(swtn1, 7985, 3) write done] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: waitup() end da: Waiting for 1 children to finish. da: waitup() start da: waitup() select on 3 (swtn1) da: waitup() Call select(), activechildren=1 da: reap() called da: waitproc() nonblocking, active children = 1... da: waitproc() done (activechildren = 1) da: reap() pid = 7985 status = 0 activechildren=1 da: waitproc() nonblocking, active children = 1... da: waitproc() done (activechildren = 1) da: reap() pid = -1 status = 31 activechildren=1 da: reap() done da: waitup() select returned -1 activechildren = 1 da: Waiting for 1 children to finish. da: waitup() start da: childscan() start da: [readchild(swtn1, 7985, 3) start] da: readchild(swtn1, 7985, 3) done: amt = -1 errno = 35 da: removechild(swtn1, 7985, 3) start da: removechild() end da: childscan() end From rdist-dev-request@usc.edu Tue Mar 29 11:41:12 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07003; Tue, 29 Mar 94 11:41:15 PST Return-Path: Received: from fievel.DaytonOH.NCR.COM (h149-25-20-80.NCR.COM) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07000; Tue, 29 Mar 94 11:41:12 PST Message-Id: <9403291941.AA07000@usc.edu> Subject: When is fromhost set? To: rdist-dev@usc.edu (Rdist Development Group) Date: Tue, 29 Mar 1994 14:41:05 -0500 (EST) From: "Tom Moore" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 464 At the start of the server() function is this bit of code: if (fromhost) { message(MT_SYSLOG, "Startup for %s", fromhost); #if defined(SETARGS) setproctitle("Serving %s", fromhost); #endif /* SETARGS */ } As best I can tell, fromhost is not and can never be other than NULL at this point. Should it be? Should this have been set in the init() function? -- Tom Moore, Electronic Information Interchange From rdist-dev-request@usc.edu Tue Mar 29 12:21:08 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08403; Tue, 29 Mar 94 12:21:09 PST Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA08399; Tue, 29 Mar 94 12:21:08 PST Received: (mcooper@localhost) by acamar.usc.edu (8.6.7/8.6.4) id MAA15836; Tue, 29 Mar 1994 12:20:59 -0800 Sender: "Michael A. Cooper" Date: Tue, 29 Mar 94 12:20:58 PST From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: "Tom Moore" Cc: rdist-dev@usc.edu (Rdist Development Group) Subject: Re: When is fromhost set? In-Reply-To: Your message of Tue, 29 Mar 1994 14:41:05 -0500 (EST) Message-Id: > At the start of the server() function is this bit of code: > > > if (fromhost) { > message(MT_SYSLOG, "Startup for %s", fromhost); > #if defined(SETARGS) > setproctitle("Serving %s", fromhost); > #endif /* SETARGS */ > } > > As best I can tell, fromhost is not and can never be other than NULL at this > point. Should it be? Should this have been set in the init() function? > > -- > Tom Moore, Electronic Information Interchange > It's set in the setargs code. mike From rdist-dev-request@usc.edu Thu Apr 14 07:23:36 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15661; Thu, 14 Apr 94 07:23:48 PDT Return-Path: Received: from swissbank.swissbank.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15652; Thu, 14 Apr 94 07:23:36 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.9) id AA04126; Thu, 14 Apr 94 09:24:00 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.8) id AA03696; Thu, 14 Apr 94 09:22:04 CDT Received: from chmail.ch.swissbank.com (chmailhost) by il.us.swissbank.com (4.1/SMI-4.1) id AA19685; Thu, 14 Apr 94 09:22:59 CDT Received: from chgvau01 by chmail.ch.swissbank.com with SMTP id AA23111 (5.67a/IDA-1.5 for ); Thu, 14 Apr 1994 16:23:04 +0200 Received: from voodoo. by chgvau01 (4.1/SMI-4.1) id AA02302; Thu, 14 Apr 94 16:21:56 +0200 Received: by voodoo. (4.1/SMI-4.1) id AA01579; Thu, 14 Apr 94 16:21:56 +0200 Date: Thu, 14 Apr 94 16:21:56 +0200 From: Boran.Sean@ch.swissbank.com (Sean Boran) Message-Id: <9404141421.AA01579@voodoo.> To: rdist-dev@usc.edu Subject: Rdist on Solaris x86 Cc: sean@chgvau01.ch.swissbank.com Currently I'm using rdist on Solarris1,2 and AIX 3.2.5. I'd like to install it now on Solaris intel. However it doesn't seem to work. Config diagnoses: OS appears to be "sunos5" I use gcc. The modules gram.c, rdist.c, client.c compile OK. However when compiling child.c I get: child.c: In function `removechild': child.c:107: `sigset_t' undeclared (first use this function) child.c:107: (Each undeclared identifier is reported only once child.c:107: for each function it appears in.) child.c:107: parse error before `set' child.c:109: `set' undeclared (first use this function) child.c:111: parse error before `)' child.c:124: parse error before `)' Has anyone succeeded with Solaris x86 (2.1)? Any suggestions. Also: rdist checks the ownership of files on the remote host. Now he seems to check the group name (as opposed to the group number). This is a big problem when you use a Sun as a server to an IBM for example. "rcp" uses group numbers, so why not rdist? Any plans to change this in the coming releases? I'll post a summary to the list. Thanks in advance, Sean |Sean Boran Tel (switz.): 022-376.44.28 | |Swiss Bank Corporation Email: Boran.Sean@ch.swissbank.com | |Geneva, Switzerland ^^^^^^^^^^ new,official addr.| |_________________________________________________________________| From rdist-dev-request@usc.edu Thu Apr 14 12:55:02 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03014; Thu, 14 Apr 94 12:55:06 PDT Return-Path: Received: from stimpy.tec.army.mil ([192.86.66.190]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03003; Thu, 14 Apr 94 12:55:02 PDT Message-Id: <9404141955.AA03003@usc.edu> Received: by stimpy.tec.army.mil (16.8/16.2) id AA05564; Thu, 14 Apr 94 15:58:01 -0400 From: Jeffrey Sullivan Subject: SGI Indigo To: rdist@usc.edu Date: Thu, 14 Apr 94 15:58:01 EDT Mailer: Elm [revision: 70.30] TWIMC, I'm in the process of compiling "rdist" on an Silicon Graphics Indigo running the IRIX 4.0.1. operating system. (System V.). The error that I receive is as follows: /usr/bin/ld: Undefined: sigmask _isexec collect2: ld returned 1 exit status *** Error code 1 Stop. Does anyone there recognize this error? If so, I would appreciate any help. Respectfully, JPS -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeffrey P. Sullivan o | | U.S. Army Topographic Engineering Center. <\ RUN! | | E-mail: sullivan@tec.army.mil /> | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rdist-dev-request@usc.edu Thu Apr 14 13:51:59 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05967; Thu, 14 Apr 94 13:52:06 PDT Return-Path: Received: from stimpy.tec.army.mil ([192.86.66.190]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05935; Thu, 14 Apr 94 13:51:59 PDT Message-Id: <9404142051.AA05935@usc.edu> Received: by stimpy.tec.army.mil (16.8/16.2) id AA05674; Thu, 14 Apr 94 16:53:28 -0400 From: Jeffrey Sullivan Subject: SG Indigo ... Update To: rdist@usc.edu Date: Thu, 14 Apr 94 16:53:27 EDT Mailer: Elm [revision: 70.30] TWIMC, I recently sent a request for help in compiling "rdist" on an SG Indigo and at the time was receiving errors such as : /usr/bin/ld: Undefined: sigmask _isexec *** Error code 1 Stop. Now I only receive : /usr/bin/ld: Undefined: _isexec *** Error code 1 Stop. Any suggestions? I corrected the first - I think - by including a BSD option in the Makefile. Respectfully, JPS -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeffrey P. Sullivan o | | U.S. Army Topographic Engineering Center. <\ RUN! | | E-mail: sullivan@tec.army.mil /> | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rdist-dev-request@usc.edu Fri Apr 15 10:33:02 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA02119; Fri, 15 Apr 94 10:35:44 PDT Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA01960; Fri, 15 Apr 94 10:33:02 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id KAA19475 for real-rdist-announce@usc.edu; Fri, 15 Apr 1994 10:33:02 -0700 Sender: "Michael A. Cooper" Date: Fri, 15 Apr 94 10:33:01 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.1beta.5 released Message-Id: Rdist version 6.1beta.5 is now available for anonymous ftp from usc.edu under /pub/rdist. I hope this to be the last 6.1 beta release. If no other major bugs are reported by May 1, then I will release version 6.1. mike From rdist-dev-request@usc.edu Sat Apr 16 00:34:02 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22705; Sat, 16 Apr 94 00:34:05 PDT Return-Path: Received: from unogate.unocal.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA22701; Sat, 16 Apr 94 00:34:02 PDT Received: from st.unocal.com (unocal.st [134.248.16.1]) by unogate.unocal.com (8.6.4/8.5) with SMTP id AAA14605; Sat, 16 Apr 1994 00:33:55 -0700 Received: from valdez.st.unocal.COM by st.unocal.com (4.1/SMI-4.1) id AA10632; Sat, 16 Apr 94 00:33:54 PDT Message-Id: <9404160733.AA10632@st.unocal.com> From: stssram@st.unocal.com (Bob Myers) Date: Sat, 16 Apr 1994 00:33:54 -0700 Organization: Unocal Exploration and Seismic Technology X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rdist-dev@usc.edu Subject: Patch for annoying problem with notify (beta5) If I'm not mistaken, there's an error in getnotifyfile(). It can return a filename even when no notify file was ever created, triggering a slew of LOCAL ERROR: /tmp/rdista8324: open for reading failed: No such file or directory messages from the notify() function. I've noticed this happening when a package has error messages coupled with the use of the -oquiet option. Any succeeding package (same invocation of rdist) that has no messages to report will trigger the above message. This has been a persistent problem with rdist-6 for us, and all versions of rdist-6 from 6.0 to 6.1beta5 have this problem. Anyway, I think this is the fix. We'll be testing this out over the next week or so. Let me know if any of you think there's any problems with this.... *** message.c.~1~ Mon Mar 14 15:26:43 1994 --- message.c Sat Apr 16 00:08:42 1994 *************** *** 861,868 **** if (msgfacility[i].mf_fptr) { (void) fclose(msgfacility[i].mf_fptr); msgfacility[i].mf_fptr = NULL; - } return(msgfacility[i].mf_filename); } return((char *) NULL); --- 861,868 ---- if (msgfacility[i].mf_fptr) { (void) fclose(msgfacility[i].mf_fptr); msgfacility[i].mf_fptr = NULL; return(msgfacility[i].mf_filename); + } } return((char *) NULL); -- Bob Myers Unocal Energy Resources Division Internet: Bob.Myers@st.unocal.com P. O. Box 68076 Phone: [714] 693-6951 Anaheim, California 92817-8076 From rdist-dev-request@usc.edu Mon Apr 18 05:38:35 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29323; Mon, 18 Apr 94 05:38:38 PDT Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29319; Mon, 18 Apr 94 05:38:35 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #2) id m0pssav-0002fPC; Mon, 18 Apr 94 08:38 EDT Message-Id: Date: Mon, 18 Apr 94 08:38 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: minor patches for hpux and linux linux cannot use SETBUF_SETLINEBUF. As of libc-4.5.21 (the last released) setlinebuf is declared to return void, which won't work. In any case, on linux setlinebuf is just emulated using setvbuf anyway. On hpux we change to the new SETBUF_SETVBUF. Also, hpux seems to already have bcopy and bzero emulations, so I don't think we need these #defines. Perhaps some old versions of hpux still need these? --- ./config/os-hpux.h-dist Wed Mar 30 23:10:14 1994 +++ ./config/os-hpux.h Mon Apr 18 08:23:42 1994 @@ -133,14 +133,15 @@ */ #include -#define bcopy(a,b,c) memcpy(b,a,c) -#define bzero(a,b) memset(a,0,b) -#define setlinebuf(a) setvbuf(a, NULL, _IOLBF, BUFSIZ) - /* * Type of set file time function available */ #define SETFTIME_TYPE SETFTIME_UTIME + +/* + * Type of set line buffering function available + */ +#define SETBUF_TYPE SETBUF_SETVBUF /* * We have fchown() --- ./config/os-linux.h-dist Wed Mar 30 23:10:16 1994 +++ ./config/os-linux.h Mon Apr 18 08:23:25 1994 @@ -133,6 +133,11 @@ #define SETFTIME_TYPE SETFTIME_UTIME /* + * Type of set line buffering function available + */ +#define SETBUF_TYPE SETBUF_SETVBUF + +/* * Path to the remote shell command. * Define this only if the pathname is different than * that which appears in "include/paths.h". From rdist-dev-request@usc.edu Tue Apr 19 22:05:49 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09201; Tue, 19 Apr 94 22:05:54 PDT Return-Path: Received: from grendel.lut.fi ([157.24.15.50]) by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09197; Tue, 19 Apr 94 22:05:49 PDT Received: (from news@localhost) by grendel.lut.fi (8.6.8/8.6.6/1.16.kim) with netnews id IAA22748; Wed, 20 Apr 1994 08:00:04 +0300 (for rdist-dev@usc.edu) To: rdist-dev@usc.edu Date: Wed, 20 Apr 1994 04:54:14 GMT From: Kimmo.Suominen@lut.fi (Kimmo Suominen) Message-Id: Organization: Lappeenranta University of Technology, Finland Sender: usenet@tac.nyc.ny.us References: Subject: Re: minor patches for hpux and linux >>>>> "Neal" == Neal Becker writes: Neal> Also, hpux seems to already have bcopy and bzero Neal> emulations, so I don't think we need these #defines. Neal> Perhaps some old versions of hpux still need these? I think pre-9 versions need the bcopy/bzero #defines. And definitely anythin pre-8 will need them. We don't have either anymore, so I cannot check for sure. -- ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ( Kimmo Suominen "That's what I think" ) ( Trans-Atlantic Communications kim@tac.nyc.ny.us ) '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From rdist-dev-request@usc.edu Wed Apr 20 11:50:44 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05611; Wed, 20 Apr 94 11:50:47 PDT Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05606; Wed, 20 Apr 94 11:50:44 PDT Received: from bb1.fid.morgan.com ([138.20.93.15]) by gateway.morgan.com with SMTP id <41891>; Wed, 20 Apr 1994 14:50:34 -0400 Received: from ruby.Morgan.COM by bb1.fid.morgan.com (4.1/MS/FID/Sun-1.2) id AA18342; Wed, 20 Apr 94 14:50:06 EDT From: dpk@morgan.com (Doug Kingston) Message-Id: <9404201450.ZM23941@ruby.fid.morgan.com> Date: Wed, 20 Apr 1994 14:50:06 -0400 X-Mailer: Z-Mail (3.0.0 15dec93) To: rdist-dev@usc.edu Subject: Efficiency change for rdist 6.1beta5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Under the new architecture, we have done away with the need for setuid permissions on the rdist binaries. This is a GOOD THING. However, we are paying a price when it comes to overhead, since every byte we send now has to be copied by two additional processes (rsh and rshd). Perhaps we could have the rdistd process create a direct connection back to the originating rdist based on a "command". I realize this would be a protocol change, but it may be worth it. I would expect that after the version exchange, the client would send a port/address to which the slave would connect. Thoughts? -Doug- From rdist-dev-request@usc.edu Wed Apr 20 12:24:46 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06790; Wed, 20 Apr 94 12:24:47 PDT Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06786; Wed, 20 Apr 94 12:24:46 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id MAA09656; Wed, 20 Apr 1994 12:24:42 -0700 Sender: "Michael A. Cooper" Date: Wed, 20 Apr 94 12:24:42 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: dpk@morgan.com (Doug Kingston) Cc: rdist-dev@usc.edu Subject: Re: Efficiency change for rdist 6.1beta5 In-Reply-To: Your message of Wed, 20 Apr 1994 14:50:06 -0400 Message-Id: Yes, something definetely needs to be done about performance when running through an external command. I haven't thought much about this yet and probably won't until after 6.1 is released. mike From rdist-dev-request@usc.edu Wed Apr 20 13:51:02 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10117; Wed, 20 Apr 94 13:51:03 PDT Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA10113; Wed, 20 Apr 94 13:51:02 PDT Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id NAA28916; Wed, 20 Apr 1994 13:51:01 -0700 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id NAA01359; Wed, 20 Apr 1994 13:47:58 -0700 Message-Id: <199404202047.NAA01359@dbeusee.us.oracle.com> Date: Wed, 20 Apr 1994 13:47:58 -0700 From: Don Beusee To: dpk@morgan.com, rdist-dev@usc.edu Subject: Re: Efficiency change for rdist 6.1beta5 The other good thing we got out of this is allowing rdist to choose a different transport. For instance, we can now make use of kerberos, but we are not limited to a tcp transport now, if someone were to write different one, to say, use serial lines. For instance, cu could probably be used to rdist files to a remote site by using something like: rdist -Pcu.rdist ... It would be nice to keep rdist seperate from the transport layer. One thing is for sure, if rdist were to start its own tcp connection, we would not be able to compress/encrypt the data like we could now by doing: rdist -Pcomp.en.rsh -puncomp.de.rdistd ... If you don't want the overhead, you can compile with -DDIRECT_RCMD. This will give you previous bahavior. The other thing that could be done is an option, like -odirecttcp, which can do what you describe. Regards, Don. From rdist-dev-request@usc.edu Wed Apr 20 12:26:43 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id MAA00292 for ; Wed, 20 Apr 1994 12:26:42 -0700 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id MAA21871; Wed, 20 Apr 1994 12:29:35 -0700 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05611; Wed, 20 Apr 94 11:50:47 PDT Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05606; Wed, 20 Apr 94 11:50:44 PDT Received: from bb1.fid.morgan.com ([138.20.93.15]) by gateway.morgan.com with SMTP id <41891>; Wed, 20 Apr 1994 14:50:34 -0400 Received: from ruby.Morgan.COM by bb1.fid.morgan.com (4.1/MS/FID/Sun-1.2) id AA18342; Wed, 20 Apr 94 14:50:06 EDT From: dpk@morgan.com (Doug Kingston) Message-Id: <9404201450.ZM23941@ruby.fid.morgan.com> Date: Wed, 20 Apr 1994 14:50:06 -0400 X-Mailer: Z-Mail (3.0.0 15dec93) To: rdist-dev@usc.edu Subject: Efficiency change for rdist 6.1beta5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: R Under the new architecture, we have done away with the need for setuid permissions on the rdist binaries. This is a GOOD THING. However, we are paying a price when it comes to overhead, since every byte we send now has to be copied by two additional processes (rsh and rshd). Perhaps we could have the rdistd process create a direct connection back to the originating rdist based on a "command". I realize this would be a protocol change, but it may be worth it. I would expect that after the version exchange, the client would send a port/address to which the slave would connect. Thoughts? -Doug- From rdist-dev-request@usc.edu Wed Apr 20 14:24:48 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11418; Wed, 20 Apr 94 14:24:53 PDT Return-Path: Received: from gateway.morgan.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA11414; Wed, 20 Apr 94 14:24:48 PDT Received: from bb1.fid.morgan.com ([138.20.93.15]) by gateway.morgan.com with SMTP id <41881>; Wed, 20 Apr 1994 17:24:33 -0400 Received: from ruby.Morgan.COM by bb1.fid.morgan.com (4.1/MS/FID/Sun-1.2) id AA20543; Wed, 20 Apr 94 17:24:09 EDT From: dpk@morgan.com (Doug Kingston) Message-Id: <9404201724.ZM23998@ruby.fid.morgan.com> Date: Wed, 20 Apr 1994 17:24:09 -0400 In-Reply-To: Don Beusee "Re: Efficiency change for rdist 6.1beta5" (Apr 20, 16:47) References: <199404202047.NAA01359@dbeusee.us.oracle.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: Don Beusee , dpk@morgan.com, rdist-dev@usc.edu Subject: Re: Efficiency change for rdist 6.1beta5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Apr 20, 16:47, Don Beusee wrote: } Subject: Re: Efficiency change for rdist 6.1beta5 ... (nice things said about transport independence) ... } It would be nice to keep rdist seperate from the transport layer. I agree. This is also a real win. } } One thing is for sure, if rdist were to start its own tcp connection, we } would not be able to compress/encrypt the data like we could now by doing: } rdist -Pcomp.en.rsh -puncomp.de.rdistd ... } While this is nice, I would suggest that for many sites this may be infact provided by hardware facilities in the future. Compressing and encrypting hardware (particularly on serial links) is a big win because it gives that advantage to ALL traffice regardless of source. I would like to have my cake and eat it too. Perhaps your "-odirecttcp" is the best way to achieve this. I expect that close to 99.9 percent of all rdist traffic will be straight TCP/IP for some time to come so it would pay to optimize it. } If you don't want the overhead, you can compile with -DDIRECT_RCMD. This } will give you previous bahavior. But I like using rsh to set up the initial process state, since we have Kerberized rsh/rshd. I don't want to have to port that every time. } } The other thing that could be done is an option, like -odirecttcp, which can } do what you describe. } } Regards, } Don. } }-- End of excerpt from Don Beusee From rdist-dev-request@usc.edu Wed Apr 20 17:41:12 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19765; Wed, 20 Apr 94 17:41:13 PDT Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA19761; Wed, 20 Apr 94 17:41:12 PDT Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id QAA11570; Wed, 20 Apr 1994 16:26:48 -0700 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id QAA03459 for rdist-dev@usc.edu; Wed, 20 Apr 1994 16:23:24 -0700 Message-Id: <199404202323.QAA03459@dbeusee.us.oracle.com> Date: Wed, 20 Apr 1994 16:23:24 -0700 From: Don Beusee To: rdist-dev@usc.edu Subject: Re: Efficiency change for rdist 6.1beta5 From dbeusee Wed Apr 20 16:23:00 1994 To: dpk@morgan.com Subject: Re: Efficiency change for rdist 6.1beta5 Status: R > I would like to have my cake and eat it too. Perhaps your "-odirecttcp" > is the best way to achieve this. I expect that close to 99.9 percent > of all rdist traffic will be straight TCP/IP for some time to come > so it would pay to optimize it. Yes, but it will not work with kerberos and other rsh replacements. This is why I think it needs to be a non-default option. Regards, Don. >From dpk@morgan.com Wed Apr 20 14:21:47 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id OAA01782 for ; Wed, 20 Apr 1994 14:21:47 -0700 Received: from gateway.morgan.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id OAA01738; Wed, 20 Apr 1994 14:24:48 -0700 Received: from bb1.fid.morgan.com ([138.20.93.15]) by gateway.morgan.com with SMTP id <41881>; Wed, 20 Apr 1994 17:24:33 -0400 Received: from ruby.Morgan.COM by bb1.fid.morgan.com (4.1/MS/FID/Sun-1.2) id AA20543; Wed, 20 Apr 94 17:24:09 EDT From: dpk@morgan.com (Doug Kingston) Message-Id: <9404201724.ZM23998@ruby.fid.morgan.com> Date: Wed, 20 Apr 1994 17:24:09 -0400 In-Reply-To: Don Beusee "Re: Efficiency change for rdist 6.1beta5" (Apr 20, 16:47) References: <199404202047.NAA01359@dbeusee.us.oracle.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: Don Beusee , dpk@morgan.com, rdist-dev@usc.edu Subject: Re: Efficiency change for rdist 6.1beta5 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: R On Apr 20, 16:47, Don Beusee wrote: } Subject: Re: Efficiency change for rdist 6.1beta5 ... (nice things said about transport independence) ... } It would be nice to keep rdist seperate from the transport layer. I agree. This is also a real win. } } One thing is for sure, if rdist were to start its own tcp connection, we } would not be able to compress/encrypt the data like we could now by doing: } rdist -Pcomp.en.rsh -puncomp.de.rdistd ... } While this is nice, I would suggest that for many sites this may be infact provided by hardware facilities in the future. Compressing and encrypting hardware (particularly on serial links) is a big win because it gives that advantage to ALL traffice regardless of source. I would like to have my cake and eat it too. Perhaps your "-odirecttcp" is the best way to achieve this. I expect that close to 99.9 percent of all rdist traffic will be straight TCP/IP for some time to come so it would pay to optimize it. } If you don't want the overhead, you can compile with -DDIRECT_RCMD. This } will give you previous bahavior. But I like using rsh to set up the initial process state, since we have Kerberized rsh/rshd. I don't want to have to port that every time. } } The other thing that could be done is an option, like -odirecttcp, which can } do what you describe. } } Regards, } Don. } }-- End of excerpt from Don Beusee From rdist-dev-request@usc.edu Thu Apr 21 17:32:51 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05541; Thu, 21 Apr 94 17:32:59 PDT Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA05537; Thu, 21 Apr 94 17:32:51 PDT Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id RAA27614; Thu, 21 Apr 1994 17:32:49 -0700 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id RAA22528; Thu, 21 Apr 1994 17:29:45 -0700 Message-Id: <199404220029.RAA22528@dbeusee.us.oracle.com> Date: Thu, 21 Apr 1994 17:29:45 -0700 From: Don Beusee To: piela@hagar.aspentec.com Subject: Re: rdist with compress Cc: rdist-dev@usc.edu Well, I confess I had not actually done it. comp.rsh would contain: #!/bin/sh compress | rsh "$@" uncomp.rdistd on the remote side would contain: uncompress | rdistd "$@" Then do: rdist -Pcomp.rsh -puncomp.rdistd ... I just tried it and it does NOT work. hmmm. I used cat instead of compress/uncompress and that does not work either. Rdistd hangs waiting for data. Hmmm.. The problem seems to be on the remote side. I can have comp.rsh do: do: cat | rsh "$@" But uncomp.rdistd does not work unless it only contains rdistd. Not even cat | rdistd works. hmmm. Looks like some special compress/uncompress s/w is required to compress/ uncompress whats available on the stdin. I guess compress/uncompress was not written with that in mind. Rats. crypt seems to have similar problems. What a bummer. Oh well, it was almost great... Regards, Don. From piela@hagar.aspentec.com Thu Apr 21 15:44:02 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id PAA20815 for ; Thu, 21 Apr 1994 15:44:01 -0700 Received: from hagar.aspentec.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id PAA19145; Thu, 21 Apr 1994 15:47:03 -0700 Received: by hagar.aspentec.com (AIX 3.2/UCB 5.64/4.03) id AA80794; Thu, 21 Apr 1994 18:41:09 -0400 Date: Thu, 21 Apr 1994 18:41:09 -0400 From: piela@hagar.aspentec.com (PETER PIELA) Message-Id: <9404212241.AA80794@hagar.aspentec.com> To: dbeusee@us Subject: rdist with compress Status: R Don, I think you wrote to me a while ago mentioning your solution for compression as described below. At that time I was using 6.0 and was unaware of the -p and -P additions. However, when I moved up to 6.1-3 I could not get a comp.sh/uncomp.sh setup to work. Would you mind giving me a little more information on your setup. Thanks. Peter } would not be able to compress/encrypt the data like we could now by doing: } rdist -Pcomp.en.rsh -puncomp.de.rdistd ... } From rdist-dev-request@usc.edu Fri Apr 22 07:07:10 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29916; Fri, 22 Apr 94 07:07:11 PDT Return-Path: Received: from postman.osf.org by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29912; Fri, 22 Apr 94 07:07:10 PDT Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA09776; Fri, 22 Apr 94 10:07:04 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA05080; Fri, 22 Apr 94 10:06:00 -0400 Date: Fri, 22 Apr 94 10:06:00 -0400 From: rsalz@osf.org Message-Id: <9404221406.AA05080@sulphur.osf.org> To: dbeusee@us.oracle.com, piela@hagar.aspentec.com Subject: Re: rdist with compress Cc: rdist-dev@usc.edu > comp.rsh would contain: > #!/bin/sh > compress | rsh "$@" > > uncomp.rdistd on the remote side would contain: > uncompress | rdistd "$@" This won't work because you need to "flush" your I/O stream; rdist communication is two-way... /r$ From rdist-dev-request@usc.edu Fri Apr 22 10:37:29 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07218; Fri, 22 Apr 94 10:38:47 PDT Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA07185; Fri, 22 Apr 94 10:37:29 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id KAA25384 for real-rdist-announce@usc.edu; Fri, 22 Apr 1994 10:37:27 -0700 Sender: "Michael A. Cooper" Date: Fri, 22 Apr 94 10:37:26 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.1beta.6 now available Message-Id: Rdist 6.1beta.6 is now out for ftp from usc.edu in /pub/rdist. Only a few items were fixed in this release. Unless someone reports a real major bug, I will release version 6.1 on May 2. I've received a number of low to medium bug reports and fixes as well as new ports. These will probably addressed in 6.1.1. mike From rdist-dev-request@usc.edu Mon May 2 06:58:46 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20284; Mon, 2 May 94 06:58:49 PDT Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA20280; Mon, 2 May 94 06:58:46 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #2) id m0pxyWA-0002fQC; Mon, 2 May 94 09:58 EDT Message-Id: Date: Mon, 2 May 94 09:58 EDT From: neal@ctd.comsat.com (Neal Becker) To: rdist-dev@usc.edu Subject: Core dump in 6.1beta6 It seems that manually aborting rdist often results in core dump! I think this should be fixed before releasing this version. This is on hpux9.01 platform. Here is an example: May 2 08:47:21 neal rdist[7121]: flyhalf: LOCAL ERROR: Lost connection to flyhalf May 2 08:47:22 neal rdist[7121]: flyhalf: LOCAL ERROR: Segmentation violation - dumping core [PID = 7121, amchild] From rdist-dev-request@usc.edu Mon May 2 08:03:45 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21871; Mon, 2 May 94 08:03:48 PDT Return-Path: Received: from amdext.amd.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21867; Mon, 2 May 94 08:03:45 PDT Received: from amdint.amd.com by amdext.amd.com with SMTP id AA24054 (5.67a/IDA-1.5+AMD for ); Mon, 2 May 1994 08:03:36 -0700 Received: from dvorak.amd.com by amdint.amd.com with SMTP id AA03551 (5.67a/IDA-1.5+AMD); Mon, 2 May 1994 08:03:34 -0700 Received: from lovecraft.amd.com by dvorak.amd.com (4.1/AMDSN-1.18) id AA19274; Mon, 2 May 94 10:01:39 CDT Received: by lovecraft.amd.com (4.1/AMDC-1.20) id AA27162; Mon, 2 May 94 10:03:32 CDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.lovecraft.amd.com.sun4.41 via MS.5.6.lovecraft.amd.com.sun4_41; Mon, 2 May 1994 10:03:32 -0500 (CDT) Message-Id: Date: Mon, 2 May 1994 10:03:32 -0500 (CDT) From: Anthony D'atri To: rdist-dev@usc.edu, neal@ctd.comsat.com (Neal Becker) Subject: Re: Core dump in 6.1beta6 In-Reply-To: References: >It seems that manually aborting rdist often results in core dump! I'd figured that it was just happening to me since nobody else had mentioned it. It's pretty anoying, too. I think the behavior started for me with b3. From rdist-dev-request@usc.edu Mon May 2 10:05:05 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25808; Mon, 2 May 94 10:05:07 PDT Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25804; Mon, 2 May 94 10:05:05 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id KAA06656; Mon, 2 May 1994 10:05:01 -0700 Sender: "Michael A. Cooper" Date: Mon, 2 May 94 10:05:00 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu Subject: Re: Core dump in 6.1beta6 In-Reply-To: Your message of Mon, 2 May 94 09:58 EDT Message-Id: Do you have a dbx stack trace? mike From rdist-dev-request@usc.edu Mon May 2 10:23:38 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26696; Mon, 2 May 94 10:23:41 PDT Return-Path: Received: from neal.ctd.comsat.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA26692; Mon, 2 May 94 10:23:38 PDT Received: by neal.ctd.comsat.com (Smail3.1.28.1 #2) id m0py1iT-0002fQC; Mon, 2 May 94 13:23 EDT Message-Id: Date: Mon, 2 May 94 13:23 EDT From: neal@ctd.comsat.com (Neal Becker) To: mcooper@usc.edu Cc: neal@ctd.comsat.com (Neal Becker), rdist-dev@usc.edu Subject: Re: Core dump in 6.1beta6 In-Reply-To: References: >>>>> "Michael" == Michael A Cooper writes: Michael> Do you have a dbx stack trace? mike No. There seems to be some bug in hpux9.01 that makes core files useless. The system doesn't even recognize them as core dumps. Since I'm not the only victim, maybe someone with a working core dump can try this? From rdist-dev-request@usc.edu Mon May 2 11:15:57 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29742; Mon, 2 May 94 11:17:44 PDT Return-Path: Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA29706; Mon, 2 May 94 11:15:57 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id LAA07208 for real-rdist-announce@usc.edu; Mon, 2 May 1994 11:15:54 -0700 Sender: "Michael A. Cooper" Date: Mon, 2 May 94 11:15:54 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: real-rdist-announce@usc.edu Subject: Rdist 6.1.0 released Message-Id: Rdist version 6.1.0 is now available on usc.edu for ftp from /pub/rdist. This is the first full release of version 6.1. I expect that there will be a 6.1.1 in 2-4 weeks. That version will fix some bugs that were not deamed critical enough to delay 6.1.0. mike From rdist-dev-request@usc.edu Mon May 2 12:58:32 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03123; Mon, 2 May 94 12:58:35 PDT Return-Path: Received: from gatekeeper.us.oracle.com by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA03118; Mon, 2 May 94 12:58:32 PDT Received: from dbeusee.us.oracle.com by gatekeeper.us.oracle.com with ESMTP (8.6.7/37.7) id MAA09368; Mon, 2 May 1994 12:58:31 -0700 Received: (dbeusee@localhost) by dbeusee.us.oracle.com (8.6.8/37.7) id MAA28571; Mon, 2 May 1994 12:55:15 -0700 Message-Id: <199405021955.MAA28571@dbeusee.us.oracle.com> Date: Mon, 2 May 1994 12:55:15 -0700 From: Don Beusee To: mcooper@usc.edu, neal@ctd.comsat.com Subject: Re: Core dump in 6.1beta6 Cc: rdist-dev@usc.edu Also include output of rdist -D. From rdist-dev-request@usc.edu Mon May 2 10:35:17 1994 Received: from gatekeeper.us.oracle.com (gatekeeper.us.oracle.com [192.216.243.3]) by dbeusee.us.oracle.com (8.6.8/37.7) with ESMTP id KAA27016 for ; Mon, 2 May 1994 10:35:16 -0700 Received: from usc.edu by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id KAA26137; Mon, 2 May 1994 10:38:20 -0700 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25808; Mon, 2 May 94 10:05:07 PDT Received: from acamar.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA25804; Mon, 2 May 94 10:05:05 PDT Received: (mcooper@localhost) by acamar.usc.edu (8.6.8.1/8.6.4) id KAA06656; Mon, 2 May 1994 10:05:01 -0700 Sender: "Michael A. Cooper" Date: Mon, 2 May 94 10:05:00 PDT From: "Michael A. Cooper" Reply-To: mcooper@usc.edu To: neal@ctd.comsat.com (Neal Becker) Cc: rdist-dev@usc.edu Subject: Re: Core dump in 6.1beta6 In-Reply-To: Your message of Mon, 2 May 94 09:58 EDT Message-Id: Status: R Do you have a dbx stack trace? mike From rdist-dev-request@usc.edu Wed May 18 09:45:49 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18369; Wed, 18 May 94 09:45:52 PDT Return-Path: Received: from animal.cs.chalmers.se by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA18364; Wed, 18 May 94 09:45:49 PDT Date: Wed, 18 May 94 18:45:47 +0200 From: Lars S|dergren Message-Id: <9405181645.AA10376@animal.cs.chalmers.se> Received: by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA10376; Wed, 18 May 94 18:45:47 +0200 To: rdist-dev@usc.edu Subject: About removing directories Cc: sodergr@cs.chalmers.se I would like rdist to be able to copy a directory tree to the remote machine. The problem is that rdist will not replace a directory with a file. Is there any reason why not to add a removedir-option or perhaps a mirror-option to make an exact copy. I had a look in server.c and it looks like it would be easy to add. I am thinking of modifying version 6.1.0, any comments? Plase respond to me too, i am not on this list. | Lars Sodergren | S-412 96 Gothenburg, Sweden | ! Unix System Manager | Phone: +46 31 7721087 | | Department of Computer Science | Fax: +46 31 165655 | | Chalmers University of Technology | Email: sodergr@cs.chalmers.se | From rdist-dev-request@usc.edu Wed May 18 11:01:45 1994 Received: by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21850; Wed, 18 May 94 11:01:47 PDT Return-Path: Received: from Princeton.EDU by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21846; Wed, 18 May 94 11:01:45 PDT Received: from ee.Princeton.EDU by Princeton.EDU (5.65b/2.110/princeton) id AA08014; Wed, 18 May 94 14:01:43 -0400 Received: from flux by ee.Princeton.EDU (8.6.5/1.112) id OAA08044; Wed, 18 May 1994 14:01:42 -0400 From: "Jay Plett" Received: by flux (4.1/ee-client) id AA02105; Wed, 18 May 94 14:01:40 EDT Date: Wed, 18 May 94 14:01:40 EDT Message-Id: <9405181801.AA02105@flux> To: rdist-dev@usc.edu, sodergr@cs.chalmers.se Subject: Re: About removing directories Reply-To: jay@Princeton.EDU On the same topic, it seems inconsistent that rdist will replace a directory with a symbolic link but will not replace a directory with a file. ...jay