Re: Rsync ssh script execution fails under cron?
Thank's, that's exactly what I'm looking for! -- I think. I've gotten it installed in root (.bashrc and .bash_profile), and I've got it working so that whenever I open a new Xterm, I can ssh to the remote without getting a passphrase request, but . . . the cron script still hangs. From reading the keychain pages, it doesn't seem like I should be starting ssh-agent or ssh-add from the cron-script, but I haven't seen any examples to be sure. I'd really appreciate it if you could give me an idea what your cron scripts look like. I must not be too far off ;) Regards, Jeff Jeff Hill Toronto Ph: 416-604-7251 Fx: 647-439-1414 At 02:43 PM 24/06/2002 -0500, Michael Procter wrote: >On Mon, Jun 24, 2002 at 03:31:58PM -0400, Jeff Hill wrote: > >I'm using keychain to run rsync from cron jobs with ssh keys that have a >passphrase -- it's probably what you're looking for: > >http://www.gentoo.org/projects/keychain.html >-- >Michael Procter >[EMAIL PROTECTED] > >-- >To unsubscribe or change options: >http://lists.samba.org/mailman/listinfo/rsync >Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: documentation bug for --daemon "use chroot" in conjunction with -o and -g
On Mon, Jun 24, 2002 at 12:24:20PM -0400, pyxl wrote: > Well, it's definitely not in either of the man pages - and those should > be the canonical documentation of rsync's behavior. But it's a small > bug (with big teeth!). > > Corey Stup wrote: > > > pyxl wrote: > > > >> Hi all, > >> > >> Tripped over a documentation bug. I'm guessing the behavior I've > >> found isn't a bug in itself as it's kind of implied by chroot (unless > >> the /etc/passwd db is read *before* you do the chroot call), so I'm > >> calling it a documentation bug. I wouldn't suggest trying to preload the password database. The password and group "databases" can easily be comming from multiple sources (nis, ldap, pam, ...) and can have tens of thousands of entries. > > > > > > I pointed out the same thing a few months ago. > > > > I believe I was told that its in the documentation, I just needed to > > know where to look. > > > > The reason it fails is that if chroot is used, the system can no > > longer access /etc/passwd (since / has changed)... > > > > I spent hours adding debug and such all over the code to try and find > > where it wasn't mapping the uid's. It is "documented" in the rsync(1) manpage in two places. under --owner: Note that if the source system is a daemon using chroot, the --numeric-ids option is implied because the source system cannot get access to the user names. and again under --numeric-ids: If the source system is a daemon using chroot, or if a user or group name does not exist on the des tination system, then the numeric id from the source system is used instead. I agree it could do with a mention in rsyncd.conf(5) under "use chroot". I also wonder about the accuracy of the entries in rsync(1). It seems to me that it wouldn't matter whether the chrooted daemon is the source or the destination. Despite the increasing use of chroot by daemons, the percentage of sysadmins who understand the implications of chroot is steadily declining and we shouldn't expect rsync users to be experts. I'm inclined to think that the chroot(1) and chroot(2) manpages really should do a better job of covering this issue. It isn't just passwd, there are a whole host of issues related to the loss of /etc /bin and paths for ld.so that will seem obscure to anyone who hasn't had to manually configure annonymous ftp. In any event. Since both of you have recently experienced this as a problem you are best qualified to propose _specific_ patchs to the manpages that might help others like yourselves. Please try to be brief as manpages should not be tutorials. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Rsync ssh script execution fails under cron?
Jeff: Sorry you got flamed. I can't imagine taking the trouble to
respond to a strangers question with only the purpose of belittling him
(though I do sometimes include manpage headers with the quotes from the
man pages, as a non-so-subtle "RTFM"). I haven't been very diligent about
keeping up with the list. I can't find your original post, so i've got to
go with what's left here.
I've used expect only incidentally, so I'm no expert there, but I often
find that programs behave differently when STDIO is a socket, fifo, pipe
... whatever your systems cron provides. I usually completely wrap things
I run from cron, as in putting them inside
++
{
script code
} &0 2>&0
++
Inside that, I may be redirecting STDIN, STDOUT, STDERR, as necessary. It
just sets to a consistent environment. I hope that helps.
I've got to learn expect myself. I've got a couple of applications
wherein it just might excel.
Good luck.
Tim Conway
[EMAIL PROTECTED]
303.682.4917 office, 3039210301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me Tim?"
Jeff Hill <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/24/2002 01:31 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
(bcc: Tim Conway/LMT/SC/PHILIPS)
Subject:Re: Rsync ssh script execution fails under cron?
Classification:
After that warm response, I decided to try for another day to get a script
working, to no avail.
Yes, a blank line and a "set -x" might be required (but certainly not
always required for all cron scripts). It made no difference here, so far.
As for the commands you didn't recognize (log_user, spawn, expect, send),
they were part of the "expect" program the script executed, something that
I thought was fairly common.
My intent was to avoid the security issues of logging into a remote server
as root without a password or passphrase. At this stage, I'm willing to
fall back to trying ssh keys without a passphrase. Again, easy enough to
implement and launch from a script directly, but it isn't going anywhere
under cron.
#! /bin/sh
#
/usr/bin/rsync -anrultvPz --delete -e
/usr/bin/ssh root@apache:"/home/jhill/" "/usr/local/bkup/home/jhill"
Setting up the keys with a blank passphrase, the above works from the
command line and requests neither password nor passphrase. But it still
doesn't work from cron. I've tried variations using ssh-add and/or
ssh-agent. I've tried running it under the Debian "crontab" that allows
for
setting the user and under the standard vixie cron. I've tried running it
as a straight command from cron, and of course as a bash script.
I'm using rsync 2.5.6cvs, Open_SSH 3.0.2p1 on Debian sid and woody
servers,
and I'm using RSA keys. I've looked at dozens of rsa-ssh scripts, but most
of them are pushing data to a remote and I need to pull it down from the
server. I've read how rsync encountered freezes with OpenSSH, in the past,
but that appears to be resolved now.
From what I've now read, it seems like I need both ssh-add and
ssh-agent.
I've created a script for cron to call and execute ssh-agent which then
calls another script to execute ssh-add and rsync:
--
rsync1:
#! /bin/sh
#
/usr/bin/ssh-agent /bin/bash /etc/rsync2
--
rsync2:
#! /bin/sh
#
/usr/bin/ssh-add /root/.ssh/id_rsa
/usr/bin/rsync -anrultvPz --delete -e "/usr/bin/ssh -A"
root@apache:"/home/jhill/" "/usr/local/bkup/home/jhill"
--
Of course, once again, it works fine from the command line but fails when
I
try it in the crontab.
At 12:03 AM 24/06/2002 +0200, Peter T. Breuer wrote:
>"A month of sundays ago Jeff Hill wrote:"
>(in immensely long lines that I have cut to 72 chars)
I didn't wrap lines to avoid problems in understanding the line breaks in
the script.
So . . ., I'd still appreciate some assistance, but if you're just going
to
'bash' me ;), I can do without it.
Regards,
Jeff
> > I'm no expert, but I've written a few scripts for cron before without
>
>You don't have an empty line at the end. You don't have a "set -x".
>These mark you out as definitely not an expert. There is no need
>to guess .. just do these two things and you will have all the info you
>need.
>
> > any problem. I appreciate that this could be considered an issue with
> > cron and not rsync, but I thought users of rsync would probably have
> > experience writing such cron scripts.
>
>Well, you know that the PATH is not the same as yours in cron, yes?
>So you should START by setting the PATH in the script.
>
> > #!/bin/sh
> > # \
> > exec expect "$0" ${1+"$@"}
>
>Error. That's an exec. We never get beyond there. And surely tehre's no
RE: RegExpr in ---exclude
On Mon, 24 Jun 2002, Bernard A Badger wrote: > Just a comment on shell glob usage [...] > Shell globbing is done before the program is invoked, so > the shell globs on "--exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]", but > unless you have a directory "--exclude=", it won't find anything. Quite so. Plus, what happens next is shell (and shell-option) dependent. Some shells always expand their args, so expanding a non-matching arg causes the entire string to vanish (a very useful thing in a script's "for" loop, but not on a command-line). Other shells complain about there being "no match" and refuse to run the command (I have my interactive shell set to do that because it helps guard against mistyped args). Just FYI. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: RegExpr in ---exclude
On Mon, 24 Jun 2002, J.Strohschnitter wrote: > is it possible to use regular expressions in the exclude-paramter of rsync ? > For example: > > rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" That's still a valid match pattern (and a poor regular expression -- "/*" would match zero or more slashes as a regex, so that would have to turn into "/.*"). What you're trying to specify is probably failing due to one or more of these problem areas: - You have to use "**" to match any depth of subdirs in between the path and the name parts. I.e. "/path/to/**/[Ff][Oo][Ll][Dd][Ee][Rr]". - Excludes anchor starting at the root of the transfer, not the root of the file system. In other words, if you're sending "/path/*", you'd have to leave off the "/path" in the exclusion. - You might want to leave off the path altogether. Using just the name "[Ff][Oo][Ll][Dd][Ee][Rr]" would exclude that name at any point in the tree. This is like specifying "**/[Ff][Oo][Ll][Dd][Ee][Rr]", but it also matches in the root dir of the transfer, and is more efficient. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: RegExpr in ---exclude
Sorry. I didn't mean to imply that the "=" is anything special, just that it shrinks the possible shell globs to the list to matching items in the "--exclude=" subdirectory. If that globs, you're using wierd filenames Not that that can't happen: tconway@alta:/users/tconway/test >find . -print . ./--exclude= ./--exclude=/path ./--exclude=/path/to ./--exclude=/path/to/a ./--exclude=/path/to/a/FoLdEr tconway@alta:/users/tconway/test > But the, that would be awfully inconvenient, wouldn't it. tconway@alta:/users/tconway/test >rm -rf * rm: unrecognized option `--exclude=' Try `rm --help' for more information. tconway@alta:/users/tconway/test >rm -rf --exclude= rm: unrecognized option `--exclude=' Try `rm --help' for more information. tconway@alta:/users/tconway/test > Nonetheless, If you don't consider what will happen to your tape drive if someone uses it for a sandwich warmer, your first support call is sure to be on that topic. Cheers, Tim Conway [EMAIL PROTECTED] 303.682.4917 office, 3039210301 cell Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), ".\n" ' "There are some who call me Tim?" "Bernard A Badger" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/24/2002 12:05 PM To: <[EMAIL PROTECTED]> cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:RE: RegExpr in ---exclude Classification: Just a comment on shell glob usage---see below. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, June 24, 2002 12:29 PM > To: J.Strohschnitter > Cc: [EMAIL PROTECTED] > Subject: Re: RegExpr in ---exclude > [SNIP] > User Commandsrsync(1) > > Change > rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" > to > rsync --exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr] > and try again. Frankly, I'm surprised you didn't get a usage message from > that one. > > Note that I removed the quotes. They are not necessary, since you won't > get any shell globbing of your pattern, because of the pattern being > connected to "--exclude" by "=". The quotes won't break anything, so you > can leave them in. Well, sort of. The "=" isn't special, is just because it's all one "word". Shell globbing is done before the program is invoked, so the shell globs on "--exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]", but unless you have a directory "--exclude=", it won't find anything. It _does_ look for it, though, so it might be kinda slow in a populous directory. It's not strictly necessary, but I don't like to advise other people to do something that "mostly" works, without making the risks clear. If you know that no such directory exists, use it. Just don't forget that you're using a loophole. Isn't there some option in some shell that causes commands to fail if a glob doesn't generate a result? If you didn't remember to enter the quotes, you could go ahead because you know what you're doing. Command syntax with globs are inherently risky, beware of files named "-?" like "-r", "-f" and "-q". That's why the "--" option was invented, to keep the glob away from the options. Be extra careful when you are writing shell scripts. They'll be invoked in ways you never imagined, so write defensively. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Rsync ssh script execution fails under cron?
On Mon, Jun 24, 2002 at 03:31:58PM -0400, Jeff Hill wrote: > > My intent was to avoid the security issues of logging into a remote server > as root without a password or passphrase. At this stage, I'm willing to > fall back to trying ssh keys without a passphrase. Again, easy enough to > implement and launch from a script directly, but it isn't going anywhere > under cron. > I'm using keychain to run rsync from cron jobs with ssh keys that have a passphrase -- it's probably what you're looking for: http://www.gentoo.org/projects/keychain.html -- Michael Procter [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Rsync ssh script execution fails under cron?
After that warm response, I decided to try for another day to get a script
working, to no avail.
Yes, a blank line and a "set -x" might be required (but certainly not
always required for all cron scripts). It made no difference here, so far.
As for the commands you didn't recognize (log_user, spawn, expect, send),
they were part of the "expect" program the script executed, something that
I thought was fairly common.
My intent was to avoid the security issues of logging into a remote server
as root without a password or passphrase. At this stage, I'm willing to
fall back to trying ssh keys without a passphrase. Again, easy enough to
implement and launch from a script directly, but it isn't going anywhere
under cron.
#! /bin/sh
#
/usr/bin/rsync -anrultvPz --delete -e
/usr/bin/ssh root@apache:"/home/jhill/" "/usr/local/bkup/home/jhill"
Setting up the keys with a blank passphrase, the above works from the
command line and requests neither password nor passphrase. But it still
doesn't work from cron. I've tried variations using ssh-add and/or
ssh-agent. I've tried running it under the Debian "crontab" that allows for
setting the user and under the standard vixie cron. I've tried running it
as a straight command from cron, and of course as a bash script.
I'm using rsync 2.5.6cvs, Open_SSH 3.0.2p1 on Debian sid and woody servers,
and I'm using RSA keys. I've looked at dozens of rsa-ssh scripts, but most
of them are pushing data to a remote and I need to pull it down from the
server. I've read how rsync encountered freezes with OpenSSH, in the past,
but that appears to be resolved now.
From what I've now read, it seems like I need both ssh-add and ssh-agent.
I've created a script for cron to call and execute ssh-agent which then
calls another script to execute ssh-add and rsync:
--
rsync1:
#! /bin/sh
#
/usr/bin/ssh-agent /bin/bash /etc/rsync2
--
rsync2:
#! /bin/sh
#
/usr/bin/ssh-add /root/.ssh/id_rsa
/usr/bin/rsync -anrultvPz --delete -e "/usr/bin/ssh -A"
root@apache:"/home/jhill/" "/usr/local/bkup/home/jhill"
--
Of course, once again, it works fine from the command line but fails when I
try it in the crontab.
At 12:03 AM 24/06/2002 +0200, Peter T. Breuer wrote:
>"A month of sundays ago Jeff Hill wrote:"
>(in immensely long lines that I have cut to 72 chars)
I didn't wrap lines to avoid problems in understanding the line breaks in
the script.
So . . ., I'd still appreciate some assistance, but if you're just going to
'bash' me ;), I can do without it.
Regards,
Jeff
> > I'm no expert, but I've written a few scripts for cron before without
>
>You don't have an empty line at the end. You don't have a "set -x".
>These mark you out as definitely not an expert. There is no need
>to guess .. just do these two things and you will have all the info you
>need.
>
> > any problem. I appreciate that this could be considered an issue with
> > cron and not rsync, but I thought users of rsync would probably have
> > experience writing such cron scripts.
>
>Well, you know that the PATH is not the same as yours in cron, yes?
>So you should START by setting the PATH in the script.
>
> > #!/bin/sh
> > # \
> > exec expect "$0" ${1+"$@"}
>
>Error. That's an exec. We never get beyond there. And surely tehre's no
>attached console at this point, so how can it possibly work? What's
>this for? Did you mean to comment it out?
>
> > # -n dry run // --progress -v for testing
> > # -z for file compression
> > log_user 0
>
>log_user is nothing I've ever heard of! What?
>
> > spawn time /usr/bin/rsync -anrultvPz --delete --exclude="vu/" -e
> /usr/bin/ssh --timeout 30 root@apache:/home/jhill/ /usr/local/bkup/home/jhill
>
>spawn? spawn? What? What's that? Are you trying to launch this in
>background? Then you want a "&". There's nothing to detach from, so
>don't waorry about it!
>
>In any case, you want to set up ssh to let you log in as root without a
>passwd. That's all.
>
>
>
> > expect "password: "
> > send "secret\n"
>
>Eh? This can't possibly do anything. This is part of a script that you
>think is taklking to something, and it is not.
>
>
>
> > log_user 1
> > interact
>
>Eh?
>
>
>It looks incredibly confused. I think you are thinking of launching
>something in the background while you deal with passwd stuff in the
>foreground. That is completely mistaken. It makes no sense.
>
>
>Set ssh to permit login without passwd for this user. That's all. It
>only needs RSA authenticatuon to be sufficient, and to have each
>others kerys in authorized_keys in .ssh both sides (well, one side,
>but you may as well have both).
>
>
>Peter
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
*****SPAM***** RE: BEN DENIZ MERHABA
SPAM: Start SpamAssassin results -- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (5.9 hits, 5 required) SPAM: Hit! (0.6 points) From: does not include a real name SPAM: Hit! (0.8 points) BODY: Uses words and phrases which indicate porn (11) SPAM: Hit! (0.1 points) BODY: Uses words and phrases which indicate porn (10) SPAM: Hit! (1.4 points) Message text disguised using base-64 encoding SPAM: Hit! (3.0 points) Listed in Razor, see http://razor.sourceforge.net/ SPAM: SPAM: End of SpamAssassin results - PGh0bWw+DQo8Ym9keT4NCg0KPGhyIGNvbG9yPSIjMDAwMDgwIj4NCg0KPHAgYWxpZ249ImNlbnRl ciI+PGZvbnQgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz48YmlnPkNBTkxJIFNFWCBTSE9XTEFSSSA8 YnI+DQpNVUhURd5FTSBU3FJLIEtJWkxBUkk8YnI+DQpIQU3dTEUgSEFUVU4gU91L3Uzd3kxFUt0g UkVT3U1MRVLdPGJyPg0KVNxSQkFOTEkgT1JPU1BVTEFSPGJyPg0KMTctMTggTElLIFRVUksgS0la TEFSSSA8YnI+DQoxMy0xOCBMSUsgWUFCQU5DSSBMT0xJVEFMQVI8YnI+DQpZ3FpMRVJDRSBURUNB VlVaIFbdREVPU1U8YnI+DQpC3U5MRVJDRSBIQVJEQ09SRSBT3Uvd3iBSRVNN3SA8YnI+DQpCVSBT 3VRFWUUgR91SRN3Q3U7dWkRFIDwvYmlnPjxicj4NCjxiaWc+JnF1b3Q7U91L3U7dWiZxdW90OyBL QUxLQUNBSzxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cub3Jvc3B1a2l6LmNvbSI+SFRUUDovL1dX Vy5PUk9TUFVLSVouQ09NPC9iaWc+PGJyPg0KPHNtYWxsPkfdUk1FSyDdx91OIFRJS0xBWUlOSVou Li48L3NtYWxsPjwvYT48L3N0cm9uZz48L2ZvbnQ+PC9wPg0KDQo8aHIgY29sb3I9IiMwMDAwODAi Pg0KDQo8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPjxiaWc+ Q0FOTEkgU0VYIE1VSEFCQkVUSSA8L2JpZz48YnI+DQo8YmlnPiAwIDA1NiA5MDIgODggMTIgPGJy Pg0KMCAwNTYgOTAyIDg4IDEzPGJyPg0KMCAwNTYgOTAyIDg4IDM0PC9iaWc+PC9zdHJvbmc+PC9m b250PjwvcD4NCg0KPGhyIGNvbG9yPSIjMDAwMDgwIj4NCg0KPHAgYWxpZ249ImNlbnRlciI+PGEg aHJlZj0iaHR0cDovL3d3dy50dXJrc2lrLmNvbS9hbS90dXJrcG9ybm8ubXBlZy5leGUiPjxmb250 DQpmYWNlPSJWZXJkYW5hIj48c3Ryb25nPjxiaWc+Qt1OTEVSQ0UgQkFL3VJFIFJFU03dIDwvYmln Pjxicj4NCjxiaWc+3U5E3VJNRUsg3cfdTiBUSUtMQVlJTklaLi4uPC9iaWc+PC9zdHJvbmc+PC9m b250PjwvYT48L3A+DQoNCjxociBjb2xvcj0iIzAwMDA4MCI+DQo8L2JvZHk+DQo8L2h0bWw+ -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
avoiding temporary files (Re: about rsync)
On 22 Jun 2002, macgiver <[EMAIL PROTECTED]> wrote: > hi > > i love rsync, but i want to know how it is possible to let rsync > download a file with the same filename, and not a temp filename like: > package.tar.gz.hzmkjz5 or so... > i don 't want to use temp filenames when downloading with rsync. Why? > Because i'm writing a program with a progress bar and it sucks with the > temp filename. That feature is quite tightly tied in to the design of rsync. We need to use a temporary filename because rsync needs access to the old file to do delta encoding, and in any case many people want the file atomically replaced when it's complete. > what do you suggest me? :( Run with --progress and read stdout, or just look for .package.tar.gz.* and see how big it is. The name is unpredictable, but there will be only one. You could even set the temporary directory to make it more predictable. Oh, and please use the list so that other people can make suggestions. > > > greetings! > > macgiver > [EMAIL PROTECTED] > -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: RegExpr in ---exclude
Just a comment on shell glob usage---see below. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, June 24, 2002 12:29 PM > To: J.Strohschnitter > Cc: [EMAIL PROTECTED] > Subject: Re: RegExpr in ---exclude > [SNIP] > User Commandsrsync(1) > > Change > rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" > to > rsync --exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr] > and try again. Frankly, I'm surprised you didn't get a usage message from > that one. > > Note that I removed the quotes. They are not necessary, since you won't > get any shell globbing of your pattern, because of the pattern being > connected to "--exclude" by "=". The quotes won't break anything, so you > can leave them in. Well, sort of. The "=" isn't special, is just because it's all one "word". Shell globbing is done before the program is invoked, so the shell globs on "--exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]", but unless you have a directory "--exclude=", it won't find anything. It _does_ look for it, though, so it might be kinda slow in a populous directory. It's not strictly necessary, but I don't like to advise other people to do something that "mostly" works, without making the risks clear. If you know that no such directory exists, use it. Just don't forget that you're using a loophole. Isn't there some option in some shell that causes commands to fail if a glob doesn't generate a result? If you didn't remember to enter the quotes, you could go ahead because you know what you're doing. Command syntax with globs are inherently risky, beware of files named "-?" like "-r", "-f" and "-q". That's why the "--" option was invented, to keep the glob away from the options. Be extra careful when you are writing shell scripts. They'll be invoked in ways you never imagined, so write defensively. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: documentation bug for --daemon "use chroot" in conjunction with-o and -g
Well, it's definitely not in either of the man pages - and those should be the canonical documentation of rsync's behavior. But it's a small bug (with big teeth!). Corey Stup wrote: > pyxl wrote: > >> Hi all, >> >> Tripped over a documentation bug. I'm guessing the behavior I've >> found isn't a bug in itself as it's kind of implied by chroot (unless >> the /etc/passwd db is read *before* you do the chroot call), so I'm >> calling it a documentation bug. > > > I pointed out the same thing a few months ago. > > I believe I was told that its in the documentation, I just needed to > know where to look. > > The reason it fails is that if chroot is used, the system can no > longer access /etc/passwd (since / has changed)... > > I spent hours adding debug and such all over the code to try and find > where it wasn't mapping the uid's. > > > > -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: RegExpr in ---exclude
I was waiting for someone more knowledgeable to respond, as the specific example you gave is covered and approved in the documentation, but i saw the "test" message sent less than 6 hours later, so I figure you must be under the gun. From the man page: oif the pattern contains a wildcard character from the set *?[ then expression matching is applied using the shell filename matching rules. Otherwise a simple string match is used. Your pattern fits this description, so it looks like you might have found a bug. rsync does not support regular expressions, but rather a simplified set of matching rules. There has been some talk about adding regex, but that's a big project. What you show, though, is not a regular expression, but a shell pattern, which should work with rsync if you fix the syntax: --exclude=PATTERN exclude files matching PATTERN SunOS 5.7 Last change: 25 Jan 20026 User Commandsrsync(1) Change rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" to rsync --exclude=/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr] and try again. Frankly, I'm surprised you didn't get a usage message from that one. Note that I removed the quotes. They are not necessary, since you won't get any shell globbing of your pattern, because of the pattern being connected to "--exclude" by "=". The quotes won't break anything, so you can leave them in. Tim Conway [EMAIL PROTECTED] 303.682.4917 office, 3039210301 cell Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), ".\n" ' "There are some who call me Tim?" "J.Strohschnitter" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/24/2002 02:30 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:RegExpr in ---exclude Classification: Hi there, is it possible to use regular expressions in the exclude-paramter of rsync ? For example: rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" I've tried it, but it will take no effect. -- SET THE CONTROLS FOR THE HEART OF THE SUN Jens -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: documentation bug for --daemon "use chroot" in conjunction with-o and -g
pyxl wrote: > Hi all, > > Tripped over a documentation bug. I'm guessing the behavior I've found > isn't a bug in itself as it's kind of implied by chroot (unless the > /etc/passwd db is read *before* you do the chroot call), so I'm calling > it a documentation bug. I pointed out the same thing a few months ago. I believe I was told that its in the documentation, I just needed to know where to look. The reason it fails is that if chroot is used, the system can no longer access /etc/passwd (since / has changed)... I spent hours adding debug and such all over the code to try and find where it wasn't mapping the uid's. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
documentation bug for --daemon "use chroot" in conjunction with -oand -g
Hi all, Tripped over a documentation bug. I'm guessing the behavior I've found isn't a bug in itself as it's kind of implied by chroot (unless the /etc/passwd db is read *before* you do the chroot call), so I'm calling it a documentation bug. The Setup: System A: running rsync --daemon from xinetd, configured with a read-only share. System B: syncing a local directory structure from the share on System A. Both running Red Hat Linux 7.2, and rsync 2.5.4 The Problem: The documentation indicates that -o and -g on the client side preserve the user and group of the files/dirs transferred as compared by name (i.e. for sync A=>B, if the uid for "bob" is 205 on A, and 3328 on B, then the uid of the file will be converted transparently to 3328 on B during a sync). HOWEVER, what isn't mentioned in the man page for either rsync or rsyncd.conf is that for the -o and -g options to work, the server side MUST have "use chroot = no" in the config file. As the default behavior for rsync is "use chroot = yes", this can make things frustrating when the directions and the behavior don't quite sync (pun gleefully intended) up. It ends up setting the uid and gid to the numeric ids from the server side, which is functionally equivalent to using --numeric-ids (with variations based on what user the client side is running as). The Solution: Mention on the rsync man page in the -o and -g descriptions that syncing from a --daemon based share requires that "use chroot = no" be specified in the rsyncd.conf, and mention on the rsyncd.conf man page that if "use chroot = no" isn't specified in the rsyncd.conf that -o and -g will not work on the client side. Thanks for your attention, Scott -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
test
test -- SET THE CONTROLS FOR THE HEART OF THE SUN Jens -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Rsync 2.5.5: FreeBSD mknod can't create FIFO's
The following patch (adapted to rsync 2.5.5 from the one posted in
Dec. 2000, http://lists.samba.org/pipermail/rsync/2000-December/003349.html)
is necessary to prevent rsync from failing on creating FIFOs or UNIX
sockets on FreeBSD. Any chance for it to be integrated in a future
release of rsync?
Thomas.
diff -ur work/rsync-2.5.5/config.h.in work.patch/rsync-2.5.5/config.h.in
--- work/rsync-2.5.5/config.h.inTue Apr 2 03:50:49 2002
+++ work.patch/rsync-2.5.5/config.h.in Mon Jun 24 14:41:48 2002
@@ -140,6 +140,9 @@
/* Define if you have the `mknod' function. */
#undef HAVE_MKNOD
+/* Define if you have the `mkfifo' function. */
+#undef HAVE_MKFIFO
+
/* Define if you have the `mtrace' function. */
#undef HAVE_MTRACE
@@ -244,6 +247,9 @@
/* Define if you have the header file. */
#undef HAVE_SYS_SOCKET_H
+
+/* Define if you have the header file. */
+#undef HAVE_SYS_UN_H
/* Define if you have the header file. */
#undef HAVE_SYS_STAT_H
diff -ur work/rsync-2.5.5/configure work.patch/rsync-2.5.5/configure
--- work/rsync-2.5.5/configure Tue Apr 2 03:50:46 2002
+++ work.patch/rsync-2.5.5/configureMon Jun 24 14:44:58 2002
@@ -4344,7 +4344,8 @@
-for ac_header in sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h
+
+for ac_header in sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h sys/un.h
do
as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
if eval "test \"\${$as_ac_Header+set}\" = set"; then
@@ -7736,7 +7737,8 @@
-for ac_func in waitpid wait4 getcwd strdup strerror chown chmod mknod
+
+for ac_func in waitpid wait4 getcwd strdup strerror chown chmod mknod mkfifo
do
as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
echo "$as_me:$LINENO: checking for $ac_func" >&5
diff -ur work/rsync-2.5.5/configure.in work.patch/rsync-2.5.5/configure.in
--- work/rsync-2.5.5/configure.in Tue Apr 2 03:41:59 2002
+++ work.patch/rsync-2.5.5/configure.in Mon Jun 24 14:42:28 2002
@@ -253,7 +253,7 @@
AC_HEADER_SYS_WAIT
AC_CHECK_HEADERS(sys/fcntl.h sys/select.h fcntl.h sys/time.h sys/unistd.h unistd.h
utime.h grp.h)
AC_CHECK_HEADERS(compat.h sys/param.h ctype.h sys/wait.h sys/ioctl.h)
-AC_CHECK_HEADERS(sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h)
+AC_CHECK_HEADERS(sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h sys/un.h)
AC_CHECK_HEADERS(glob.h alloca.h mcheck.h sys/sysctl.h arpa/inet.h arpa/nameser.h)
AC_CHECK_HEADERS(netdb.h)
AC_CHECK_HEADERS(malloc.h)
@@ -359,7 +359,7 @@
dnl AC_FUNC_MEMCMP
AC_FUNC_UTIME_NULL
-AC_CHECK_FUNCS(waitpid wait4 getcwd strdup strerror chown chmod mknod)
+AC_CHECK_FUNCS(waitpid wait4 getcwd strdup strerror chown chmod mknod mkfifo)
AC_CHECK_FUNCS(fchmod fstat strchr readlink link utime utimes strftime)
AC_CHECK_FUNCS(memmove lchown vsnprintf snprintf asprintf setsid glob strpbrk)
AC_CHECK_FUNCS(strlcat strlcpy mtrace mallinfo setgroups)
diff -ur work/rsync-2.5.5/rsync.h work.patch/rsync-2.5.5/rsync.h
--- work/rsync-2.5.5/rsync.hMon Jun 24 14:53:36 2002
+++ work.patch/rsync-2.5.5/rsync.h Mon Jun 24 14:45:25 2002
@@ -108,6 +108,10 @@
#ifdef HAVE_SYS_SOCKET_H
#include
+#endif
+
+#ifdef HAVE_SYS_UN_H
+#include
#endif
#ifdef HAVE_STRING_H
diff -ur work/rsync-2.5.5/syscall.c work.patch/rsync-2.5.5/syscall.c
--- work/rsync-2.5.5/syscall.c Mon Mar 25 04:51:17 2002
+++ work.patch/rsync-2.5.5/syscall.cMon Jun 24 14:46:19 2002
@@ -67,6 +67,35 @@
{
if (dry_run) return 0;
CHECK_RO
+
+#if HAVE_MKFIFO
+ if (S_ISFIFO(mode)) {
+ return mkfifo(pathname, mode);
+ }
+#endif
+
+#if HAVE_SYS_UN_H
+ if (S_ISSOCK(mode)) {
+ int sock;
+ struct sockaddr_un saddr;
+ int len = strlen(pathname) + 1; /* include null */
+
+ saddr.sun_family = AF_UNIX;
+ strncpy(saddr.sun_path, pathname, sizeof(saddr.sun_path));
+ saddr.sun_len = len > sizeof(saddr.sun_path) ? sizeof(saddr.sun_path)
+: len;
+
+ if ((sock = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) {
+ return -1;
+ }
+ unlink(pathname);
+ if ((bind(sock, (struct sockaddr*)&saddr, sizeof(saddr))) < 0) {
+ return -1;
+ }
+ close(sock);
+ return do_chmod(pathname, mode);
+ }
+#endif
+
return mknod(pathname, mode, dev);
}
#endif
--
[EMAIL PROTECTED]
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RegExpr in ---exclude
Hi there, is it possible to use regular expressions in the exclude-paramter of rsync ? For example: rsync --exclude "/path/to/*/[Ff][Oo][Ll][Dd][Ee][Rr]" I've tried it, but it will take no effect. -- SET THE CONTROLS FOR THE HEART OF THE SUN Jens -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
