Re: [rdiff-backup-users] rdiff-backup-statistics on OSX?

[Carsten Lorenz]

If rdiff-backup isn't in your $PATH you may specify the path by adding an
option like this to your rdiff-backup commandline:

--remote-schema "ssh -C %s /usr/local/bin/rdiff-backup --server"

Carsten


Am 19.10.2006 21:38 Uhr schrieb "gardyloo" unter <address@hidden>:

>    Many thanks to Jim Nasby and Chris Wilson. Both have suggested some
> (related) things for me to try. I will not have time to try these until
> possibly several days from now, but I will get back to the list with
> what I've found. One problem is that I'm *somewhat* familiar with linux,
> and only vaguely familiar with ssh, and OSX, despite being a *NIX
> variant at heart, seems to do some things in ways which are totally
> confusing to me. So it will take me some time to learn which tricks to try.
> 
>         Thanks for readers' forbearance, and the list's help!
> 
>              Curtis O.
> 
> Chris Wilson wrote:
>> Hi Gardyloo,
>> 
>> On Thu, 19 Oct 2006, gardyloo wrote:
>> 
>>>     However, now if I run rdiff-backup-statistics on the OSX machine,
>>> it still gives me "no matching sessions found" (I know I'm running it
>>> on the correct directory). I also tried "rdiff-backup -l", and it
>>> gives me "Found 0 increments".  Also I just tried to do a tiny sample
>>> restore (from the linux machine). Here is the resulting message:
>>> 
>>>     bash: line 1: rdiff-backup: command not found
>>> Fatal Error: Truncated header string (problem probably originated
>>> remotely)
>> [...]
>>>    I'm not sure I trust this, because I have set up the PATH on that
>>> machine to include /sw/bin (where rdiff-backup and
>>> rdiff-backup-statistics are), and starting to type rdiff-b on the
>>> command line will tab-complete properly.
>> 
>> That doesn't necessarily mean that sshd is using your new path. If you
>> added /sw/bin to your PATH in /etc/profile or ~/.profile, those files
>> are not read (I think) when yu ssh to execute a command, becaue sshd
>> doesn't start a login shell (which would read profiles) and sshd's own
>> environment might not contain the new PATH entry. You can check that
>> by running this command on the MacOS X box:
>> 
>>     sudo ps auxwwe | grep sshd | grep -v grep
>> 
>> and verify whether it shows the updated path. If not, try restarting
>> sshd from a shell that definitely has the new environment, as root
>> (not using sudo).
>> 
>>> Also, wouldn't this same message properly appear if the backup in the
>>> first place couldn't happen (yet I can run that properly from the
>>> linux machine)?
>> 
>> Yes, it should be the same, but please try the above command. If you
>> use SSH keys for authentication then possibly the settings used by
>> sshd might be different depending on which keys is being used.
>> 
>> Cheers, Chris.