rsync daemon only accessable as root
Hi, I'm trying to setup an rsync daemon such that I can synchronize my home pc (or other remote system) with my pc at work. I'm fairly new to linux and am just starting to learn its amazing possibilities. I followed an online toturial to create a rsyncd.conf file which reads: #motd file = /etc/rsyncd.motd log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock refuse options = delete [test] path = /home/user/test comment = rsync test use chroot = yes gid = nobody uid = nobody read only = no list = yes auth users = user secrets file = /etc/rsyncd.secrets # Limit access from LAN hosts allow=127.0.0.1, home-ip hosts deny=* Then I start the daemon as: sudo rsync -daemon (as user it doesn't seem to start). Now when I am at home I can only access the daemon using: rsync -av -e ssh -l root user@host-ip::test /dest i.e. it will only function as root, which is undesirable. I'd like to use something like: rsync -av -e ssh -l ssh-user user@host-ip::test /dest, but this produces the error rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(463) [receiver=2.6.8] What am I overlooking? I hope someone can help me, Regards, Peter -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
Lawrence D. Dunn wrote: Colleagues, If you do pursue SSL functionality directly in rsync, please be sure to take a look at Chris Rapier's work to fix standard ssh implementations, at: http://www.psc.edu/networking/projects/hpn-ssh/ Turns out -e ssh using most libraries puts a fixed-window-size ssh-windowing behavior on top of TCP - so for large bandwidth*delay product paths, even if you use large TCP buffers (which Wayne added for such paths), an un-fixed SSL library can clobber overall performance/throughput, even for a perfectly clean (no errors/loss) path. SSL != SSH. -- Carson -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
On 4/18/07, Carson Gaspar [EMAIL PROTECTED] wrote: Lawrence D. Dunn wrote: Colleagues, If you do pursue SSL functionality directly in rsync, please be sure to take a look at Chris Rapier's work to fix standard ssh implementations, at: http://www.psc.edu/networking/projects/hpn-ssh/ Turns out -e ssh using most libraries puts a fixed-window-size ssh-windowing behavior on top of TCP - so for large bandwidth*delay product paths, even if you use large TCP buffers (which Wayne added for such paths), an un-fixed SSL library can clobber overall performance/throughput, even for a perfectly clean (no errors/loss) path. SSL != SSH. This still applies (depending on the ssl toolkit being used). The problem referenced here is the TCP window size is hard coded inside the openssl library. In order to change the window size, one must patch openssl. Of course, there is also the question of if openssl is the appropriate toolkit to use with rsync. I am not sure of the issues with a GPL binary linking against a BSD library. Perhaps GnuTLS is more appropriate... (I know... this is probably a whole different can of worms. :-) ). -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
Aaron W Morris wrote: On 4/18/07, Carson Gaspar [EMAIL PROTECTED] wrote: Lawrence D. Dunn wrote: Colleagues, If you do pursue SSL functionality directly in rsync, please be sure to take a look at Chris Rapier's work to fix standard ssh implementations, at: http://www.psc.edu/networking/projects/hpn-ssh/ Turns out -e ssh using most libraries puts a fixed-window-size ssh-windowing behavior on top of TCP - so for large bandwidth*delay product paths, even if you use large TCP buffers (which Wayne added for such paths), an un-fixed SSL library can clobber overall performance/throughput, even for a perfectly clean (no errors/loss) path. SSL != SSH. This still applies (depending on the ssl toolkit being used). The problem referenced here is the TCP window size is hard coded inside the openssl library. In order to change the window size, one must patch openssl. TCP window size is not, and can not, be hard coded inside openssl. Do you know what TCP window size is? Of course, there is also the question of if openssl is the appropriate toolkit to use with rsync. I am not sure of the issues with a GPL binary linking against a BSD library. Perhaps GnuTLS is more appropriate... (I know... this is probably a whole different can of worms. :-) ). There is no license issue. This is just a troll. -- Carson -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 that was a little harsh Carson Gaspar wrote: Aaron W Morris wrote: On 4/18/07, Carson Gaspar [EMAIL PROTECTED] wrote: Lawrence D. Dunn wrote: Colleagues, If you do pursue SSL functionality directly in rsync, please be sure to take a look at Chris Rapier's work to fix standard ssh implementations, at: http://www.psc.edu/networking/projects/hpn-ssh/ Turns out -e ssh using most libraries puts a fixed-window-size ssh-windowing behavior on top of TCP - so for large bandwidth*delay product paths, even if you use large TCP buffers (which Wayne added for such paths), an un-fixed SSL library can clobber overall performance/throughput, even for a perfectly clean (no errors/loss) path. SSL != SSH. This still applies (depending on the ssl toolkit being used). The problem referenced here is the TCP window size is hard coded inside the openssl library. In order to change the window size, one must patch openssl. TCP window size is not, and can not, be hard coded inside openssl. Do you know what TCP window size is? Of course, there is also the question of if openssl is the appropriate toolkit to use with rsync. I am not sure of the issues with a GPL binary linking against a BSD library. Perhaps GnuTLS is more appropriate... (I know... this is probably a whole different can of worms. :-) ). There is no license issue. This is just a troll. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJpznVUgmzOrz1gcRAlQBAJsG2QaqebNMojq0gWk/O8q14gtj/QCcC35L Fs+lgsA5vUoWPdvp4s6FLhQ= =oBwN -END PGP SIGNATURE- -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
why does --size-only not detect change only is size (but also time)?
Hi, I'm wondering why when I use --size-only on the same file, except the modification time, rsync transfers the modification time? I was under the impression that --size-only caused rsync to transfer files based upon differences in the size of the file. For example: #cp Untitled.pdf Untitled-2.pdf #touch Untitled.pdf #rsync -ani --size-only Untitled.pdf Untitled-2.pdf .f..t.. Untitled.pdf #ls -al --block-size=1 Untitled* -rw--- 1 csights csights 20696 2007-04-18 19:00 Untitled-2.pdf -rw--- 1 csights csights 20696 2007-04-18 19:08 Untitled.pdf It seems to me as though this file should not be transfered because the sizes are the same. Thanks, C. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On Wed, Apr 18, 2007 at 07:37:44PM -0400, CSights wrote: #rsync -ani --size-only Untitled.pdf Untitled-2.pdf .f..t.. Untitled.pdf The file was not transferred (since there was not '' or '' in the first character). The time was changed due to the --times option being implied by -a. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On 4/18/07, CSights [EMAIL PROTECTED] wrote: I'm wondering why when I use --size-only on the same file, except the modification time, rsync transfers the modification time? I was under the impression that --size-only caused rsync to transfer files based upon differences in the size of the file. [...] #rsync -ani --size-only Untitled.pdf Untitled-2.pdf .f..t.. Untitled.pdf [...] It seems to me as though this file should not be transfered because the sizes are the same. The first character of the itemize line is a period, which means that rsync decided that the file's data was the same on both sides and thus didn't transfer the file per se. (If rsync did transfer it, the character would be a or .) All rsync did was copy the mtime, which you asked it to do by passing -a, which includes --times. If you don't want to copy mtimes at all, add --no-times somewhere after the -a on the command line. Then transferred files will have their mtimes set to the current time by virtue of rsync modifying their data, while other files' mtimes will be left alone. I don't think there's a way to copy mtimes on transferred files but not already up-to-date files. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
This still applies (depending on the ssl toolkit being used). The problem referenced here is the TCP window size is hard coded inside the openssl library. In order to change the window size, one must patch openssl. TCP window size is not, and can not, be hard coded inside openssl. Do you know what TCP window size is? Of course, there is also the question of if openssl is the appropriate toolkit to use with rsync. I am not sure of the issues with a GPL binary linking against a BSD library. Perhaps GnuTLS is more appropriate... (I know... this is probably a whole different can of worms. :-) ). There is no license issue. This is just a troll. that was a little harsh I'll say. Completely uncalled for and unprofessional. There is no need for name calling here. I can admit when I'm wrong. I apologize for any mis-information, I was just trying to help. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On Wednesday 18 April 2007 19:55, Wayne Davison wrote: On Wed, Apr 18, 2007 at 07:37:44PM -0400, CSights wrote: #rsync -ani --size-only Untitled.pdf Untitled-2.pdf .f..t.. Untitled.pdf The file was not transferred (since there was not '' or '' in the first character). The time was changed due to the --times option being implied by -a. ..wayne.. Oops, Yes, the file was not actually transferred because I used the -n option. My mistake, I was using -n to show what would happen and confused things. I also understand that the file's time would be updated with no -n because --times was specified. Sorry for the confusion! :) My confusion is that when using --size-only only the size should be used by rsync to decide whether the files are different. In this case the files' sizes are the same, but the times are different. rsync must be looking at the files' times as well, which seems to contradict the manual page. --size-only [...] With the --size-only option, files will not be transferred if they have the same size, regardless of timestamp. [...] Thanks again, C. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
Hello, * Aaron W Morris [EMAIL PROTECTED] [20070419 02:25]: This still applies (depending on the ssl toolkit being used). The problem referenced here is the TCP window size is hard coded inside the openssl library. In order to change the window size, one must patch openssl. TCP window size is not, and can not, be hard coded inside openssl. Do you know what TCP window size is? well, tuning the TCP parameters can (which is basically what the patch does), but I think this should be left to the kernel / OS via sysctl and the like, so I won't touch what's happening there. Of course, there is also the question of if openssl is the appropriate toolkit to use with rsync. I am not sure of the issues with a GPL binary linking against a BSD library. Perhaps GnuTLS is more appropriate... (I know... this is probably a whole different can of worms. :-) ). There is no license issue. There would be a serious licence issue the other way round, but BSD is a tad more permissive than the GPL is, so - no problem there BUT: there is an advertisement clause, so rsync would need to display certain messages when compiled with OpenSSL. I'm used to working with the OpenSSL (and ssleay before) API, but I suppose I'd enjoy learning gnutls as well - albeit it's not as self-contained as OpenSSL is (hello gnupg!), and the API is quite different (OpenSSL has grown to it's current state, when gnutls was started they already knew what's about to be required). The planned features would have to be revised, as it doesn't support hardware engines (which the bulk of the users won't use anyway and seldom can cope compared to raw CPU power in the long run) and could possibly offer more/other stuff than OpenSSL does. In the end, both have my confidence (the code is mature and well in production use, so lots of bugs have already been shaken loose), the basic featureset is the same - and while I'll look at the OpenSSL-patch, I'll not necessarily base my work directly on it - not much harm done changing horses before the real race. Opinions? This is just a troll. just who exactly are you talking about? ;) Best regards, Andreas -- God is a comedian playing to an audience too afraid to laugh. -- H.L.Mencken -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On Wed, Apr 18, 2007 at 08:40:40PM -0400, CSights wrote: Yes, the file was not actually transferred because I used the -n option. The -n is irrelevant. If rsync considered the file to be in need of a transfer, it would have output a file-transfer character in the first column of the -i output. Since it output a period, it is just telling you that the file needed an attribute tweaked -- in this case, the mod- ified time (the 't' in the output). If rsync were adjusting some other preserved attribute, it would have output that letter as well (or instead). For instance, if a file just needed its group tweaked, it might look like this: .f.g... Untitled.pdf See Matt's answer for a discussion of how --no-times can be used. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On 4/18/07, CSights [EMAIL PROTECTED] wrote: My confusion is that when using --size-only only the size should be used by rsync to decide whether the files are different. In this case the files' sizes are the same, but the times are different. rsync must be looking at the files' times as well, which seems to contradict the manual page. Just to drive the point home: Transferring refers specifically to copying the *data* of a regular file from sender to receiver and is only one of several things that rsync can do to a file. The others: rsync can locally create files (usually only non-regular files), hard-link them, delete them, and tweak their attributes. The first character of an itemize line tells you the kind of processing: or for a transfer, c for a local creation, h for a hard link, * for a deletion, and . for none of the preceding. Attribute tweaks are indicated by additional letters after the file type letter. The options --size-only, --checksum, and --ignore-times govern only the quick check, i.e., the decision of whether a regular file looks up-to-date enough to not be transferred. *Regardless of this decision*, the file is considered for attribute tweaking in accordance with the attributes you asked rsync to preserve. This means that attribute changes, such as your change to the mtime, will be propagated whether or not they cause the quick check criterion you selected to fail. As Wayne said, -n is irrelevant. The dry-run output reflects all the actions (data transfer, attribute tweaks, or both) that rsync would perform on a real run; it is considered a bug if the dry-run output differs from the real-run output. On a real run, the itemize line for Untitled.pdf would still be .f..t.., indicating that rsync did not transfer it but did tweak the mtime. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: why does --size-only not detect change only is size (but also time)?
On Wednesday 18 April 2007 21:03, Wayne Davison wrote: On Wed, Apr 18, 2007 at 08:40:40PM -0400, CSights wrote: Yes, the file was not actually transferred because I used the -n option. The -n is irrelevant. If rsync considered the file to be in need of a transfer, it would have output a file-transfer character in the first column of the -i output. Since it output a period, it is just telling you that the file needed an attribute tweaked -- in this case, the mod- ified time (the 't' in the output). If rsync were adjusting some other preserved attribute, it would have output that letter as well (or instead). For instance, if a file just needed its group tweaked, it might look like this: .f.g... Untitled.pdf See Matt's answer for a discussion of how --no-times can be used. ..wayne.. Ah, So with --size-only rsync still compares the modification times and other metadata and then tweaks these on the receiving file. (.f..t..) With the default file comparison algorithm rsync compares , creates a new file on the receiver to be identical to the sender, then deletes the original file on the receiver and moves the new file into place. (f..t..) That can be a big difference in behavior! E.g. In the default behavior hard symlinks are broken, but with --size-only they are not. IMHO it would be nice if --size-only (and --checksum, --ignore-size) only changed how the are the files different decision was made, not how the file was updated. Different switches could be used for the file update behavior, e.g. switches like --inplace. Thanks for the clarifications (and of course rsync), C. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Abbestellen erfolgreich
Title: Newsletter der Wirtschaftskammer Schweiz-Bulgarien 01-2005 - Wirtschaftskammer Schweiz-Bulgarien Abbestellen erfolgreich Ihre Emailadresse rsync@lists.samba.org wurde erfolgreich aus der Mailingliste der Wirtschaftskammer Schweiz-Bulgarien gelscht. Schade, dass Sie nicht mehr dabei sind! -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync SSL 'for real'
On 4/18/07, Andreas Kotes [EMAIL PROTECTED] wrote: This is just a troll. just who exactly are you talking about? ;) Ahem... That would be me. That will be $10 for posting in this list. :-) -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
