similar to: exclude vs include

When using the -z and -B65536 options together, sometimes there is file corruption. Client and server are both compiled against zlib 1.1.4, so the gzip corruption shouldn't be there, right? With -z and -B32768 there is an error, but it is detected in a different way. With -B65536 and without -z all seems to be going OK. With -B16384 and with -z all seems to be going OK. I'm guessing

I was under the impression that --include and --exclude worked by matching patterns in the order given, and whichever matched first, whether that was an include or exclude determined the action for that file. I have a big directory from which I am attempting to transfer selected files. I want all files where the first level directory is anything, the second level directory is "2005"

This problem has persisted for as long as I've used rsync. When the --delete option is used, not all files are deleted from the target, even though said files are not present in the source. The particular cases that cause this are when the target has a directory with files, and the source is something else, at least a symlink (this is the case I have seen). I'm taking a guess to say that

I'm trying to set up a machine which will be running multiple instances of NSD to serve different sets of zones from different interfaces. What I'm running into is that I can't specify different PID files to refer to on the command line. Are there any shortcuts or do I need to go write a patch? Any other implications of multiple instances? --

It guess I still haven't figured out the entire sematics of the --include and --exclude options. From reading the man page, it seems to say that what happens is that each file being checked is tested against each pattern in order, and when one matches the tests end, and whether it is --include or --exclude determines if that file is included or excluded. So I have on my server a big file

A while back, I asked if there had been any consideration in making rsync support direct ssl (as opposed to just ssh). I've been looking around for a secure way (e.g. encrypted, so passwords are never in the clear, and even content is obscured from sniffers) to allow a set of limited-trust users (limited-trust being defined as mostly customers, whom you trust with their own data, but not with

I think someone posted this before, but I can't find it in the archives. I am using rsync to pull down source files to be compiled. The delete options are used to clear out any old files left over from previous. Normally this works. I've run into one case where it persistently fails. Within the directory created during compiling is a symlink to another directory, also created during

If I understand privsep correctly, and I'm not sure I do as there are some ambiguities in the illustration of what processes are doing what, there is a way to avoid doing fd passing. What I see is that fd passing is done to send the PTY to the user privileged process after the monitor process was requested to set one up. Why not go ahead and have the monitor set one up before it forks the

After doing a fresh extraction of the source for 2.6.0, I execute ./configure and it enters a loop with no output before or during. I let run 20 minutes just to see if it would ever do anything and it did nothing else. Host system has: Linux: 2.4.23 Slakcware: 9.0 bash: 2.05b.0 gcc: 3.2.2 glibc: 2.3.1 I have a big (huge) strace of it here:

I have an openssh RPM package that restarts the sshd server during an upgrade if the daemon is already running. So far, so good, restart works. But I observed the following behaviour: - when issuing rpm -Uvh bla.rpm, rpm, obviously, opens the rpm file and gets a file descriptor. Say, 8. - rpm does its stuff and spawns a shell to execute the %post script. The shell also gets fd 8 (should rpm

Under certain circumstances (repeatable with a workaround) the client in openssh-2.1.1p3 and p4 closes file descriptors and then calls select() with the stderr one in the write fd_set. The circumstances which cause this appears to be that the closing of stdin/stdout/stderr occurs before the last of the stderr data is written to stderr. This occurs when a tty is not allocated, but the error

I get this error: ============================================================================= KLIBCCC usr/kinit/resume.o usr/kinit/resume.c:15:66: linux/config.h: No such file or directory make[2]: *** [usr/kinit/resume.o] Error 1 make[1]: *** [all] Error 2 make: *** [klibc] Error 2 ============================================================================= There is no linux/config.h in

I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have more than one daemon with separate executable images). After upgrading from 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing over the existing image), I do SIGHUP and get this message logged: Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting. Sep 16 15:07:36 vega

How hard would it be to have rsync do the file recursion scan on both the source tree and the destination tree at the same time in parallel? Would that require a protocol change, or could just a program change be enough? I have some very large directories I'd like to syncronize. Total time to scan through these millions of files is a substantial portion of an hour or even exceeds it. It

Now that I got klibc to build, the next step is to leanr what it takes to compile ... and most importantly, link ... a program with klibc. Past experience with the GNU toolchain tells me GCC will be a bit of a trouble maker in this, probably trying to make inappropriate library references that would work fine with glibc. I do not currently have any intent to make shared/dynamically linked

The cause is, of course, that the tree being syncronized ie getting larger, so of course rsync is slowing down. But in the case of my particular file tree, there is a way it could be speeded up, but this would obviously also need a change in the rsync protocol to accomplish it. Any tree that has major unchanged subbranches would benefit from this. The file tree I'm syncronizing in this case

Hi; I just attempted to install openssh-3.3p1 on a Sparc box running linux kernel 2.2.14-5.0 However any attempt to connect to the daemon causes a crash. (See below) Given the current security issue, will there be an available option for running the up coming 3.4 release on a Linux 2.2 kernel? Bob ><> ><> ><> ><> ><> ><>

http://www.eviladmin.org/~mouring/openssh.tar.gz If there are any issues that are not marked as known. Let us know ASAP. - Ben

Does anybody care about supporting non-English message locales in rsync? (Do all sysadmins speak English? :-) Would anybody contribute translations if we had the framework? -- Martin

[garbage in Chinese snipped] Is there any way to set up a post-confirmation system for non-subscribers so that their posts do not get distributed unless they confirm first? -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |