It's possible to use rsync without rsh, as noted. a local transfer (src and dst on same machine) does not use rsh
a transfer to an rsync server (an rsync started with --daemon or set up through inetd/xinted to listen on port 873) does not use rsh I think rsh usage is there as a convenience to avoid having to set up one more server if you could just piggyback on rsh (or ssh) already being configured between the machines in question. -----Original Message----- From: Marvin Heffler [mailto:[EMAIL PROTECTED] Sent: Saturday, December 01, 2001 9:53 AM To: Wichmann, Mats D Cc: Stuart Anderson; [EMAIL PROTECTED]; Chris Yeoh; George Kraft; [EMAIL PROTECTED] Subject: RE: Testing of lsbdev and sample implementation I think rsync was chosen as the sample application to test lsbdev because it is one of the commands listed by the LSB spec that needs to be on an LSB compliant system. Since rsync needs rsh to do any client-side operations, then it sounds to me like the LSB should add rsh to its command list. Of course doing this opens up the same question for all the other commands listed in the LSB. If any of them are like rsync and need a command that is not in the LSB, then we need to find this out and handle them accordingly. Hopefully, most of the commands will not be like rsync by relying on the use of other commands instead of library calls. Regards, Marvin Heffler Linux Standard Base and Developers Toolbox IBM Linux Technology Center 11400 Burnet Road, Zip 908-1A33 Austin, TX 78758 (512) 838-0953 T/L 678-0953 "Wichmann, Mats D" <[EMAIL PROTECTED]> on 11/30/2001 01:36:07 PM To: Stuart Anderson <[EMAIL PROTECTED]>, Marvin Heffler/Austin/[EMAIL PROTECTED] cc: [EMAIL PROTECTED], Chris Yeoh/Australia/[EMAIL PROTECTED], George Kraft/Austin/[EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Testing of lsbdev and sample implementation Hmpf. Rsync probably shouldn't have been chosen as a sample application for the reason that it calls external programs to handle the transfer (usually; there's a connect-to-rsync-server mode that I believe does not). However, here's a question: can an LSB application call out to a non-LSB application "legally"? While it's doing so, /that/ usage isn't LSB-conforming, but does that make the application itself unable to be used as an LSB application? And... are there any plans for a dynamic application checker that could alert one to such issues, since a static checker can't find this sort of problem - it's not known until runtime which external program will be launched, since that's controllable by environment variable and/or command-line option. In fact, rsh and ssh could hypothetically be made part of the spec and rsync could still be called in a way that it lanuches yet another program that's not part of the spec... Mats -----Original Message----- From: Stuart Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2001 11:42 AM To: Marvin Heffler Cc: [EMAIL PROTECTED]; Chris Yeoh; George Kraft; [EMAIL PROTECTED] Subject: Re: Testing of lsbdev and sample implementation Technically, if rsh isn't a LSB specified command, then it shouldn't be in SI, and an application shouldn't be calling out to it. Possibly, we need to add rsh (and ssh), but it should be added to the spec first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
