Now that I have rsync working, I have now combined it with plink. I use rsync to update the server with some large VFP applications. This is a slow process because of my Internet 'up speed' on the development server. Because of this, I rsync every file that needs to be in any URL to a single folder. Then I use plink to copy each file to the URL where clients and various Medicare contractors and payers will download. Here is the plink code.
plink webxxx.webfaction.com -l webfactaccount -pw mypassword -ssh -v -L port#:localhost:port# -m copylist.txt The file: copylist.txt has Linux copy commands like this: cp /home/webfactaccount/webapps/baseaccount_com/file1.exe /home/webfactaccount/webapps/www_domain1_com/path1 cp /home/webfactaccount/webapps/baseaccount_com/file2.exe /home/webfactaccount/webapps/www_domain1_com/path2 cp /home/webfactaccount/webapps/baseaccount_com/file1.exe /home/webfactaccount/webapps/www_domain2_com/path1 cp /home/webfactaccount/webapps/baseaccount_com/file2.exe /home/webfactaccount/webapps/www_domain2_com/path2 This method works in about 15 minutes if 5 or 6 large files change. if I used rsync or ftp to update each domain/URL it would take about 2-3 hours. The reason is that plink can copy from one URL to another URL (on the same server) very fast. I am using webfaction because it was recommended on this list. You can have one account with as many different domains/URLs as you want for a fixed price based on how much total storage you use. Hope that is clear. ----- Original Message ----- From: "Malcolm Greene" <[email protected]> To: <[email protected]> Sent: Wednesday, June 23, 2010 12:49 PM Subject: Re: [NF] Rsync usage scenario? (creating host keys that work underWindows) Paul, I'm struggling with the same (Windows) issues Ken is so thank you very much for having the patience to share your technique. Any comments you have on the following questions would be greatly appreciated. 1. In reviewing your instructions, it appears that you have 3 different client side locations for the Windows equivalent of home - it looks like you have multiple .ssh folders on your client side? - c:\cygwin\home - /home/Administrator/.ssh/id_dsa.pub - c:\cygwin\Administrator\.ssh 2. On the server side, why do you use .ssh/authorized_keys2 vs. .ssh/authorized_keys (same file without the '2' prefix)? I'm guessing this has something to do with SSH vs. SSH2? The instructions I've been reading on the web use the 'authorized_keys' file name. 3. Don't you need to register your server's public key on your client via something like this or is this an optional step? cat your-server_dsa.pub >> /home/Administrator/.ssh/known_hosts file 4. Any specific reason for choosing DSA vs. RSA to generate your key? THANK YOU :) Malcolm <snipped> Ok, the key difference on Windows using Cygwin versus *nix machines is that there's no /home directory. /home is underneath whereever cygwin is installed, usually c:\cygwin\home. Here's what I did on my Vista machine, in Windows Terminal, to enable passwordless logins to my server: ssh-keygen -t dsa <press enter through every prompt> <make a note of the directory where it tells you the key is installed, for me it was /home/Administrator/.ssh/id_dsa.pub> c: cd c:\cygwin\Administrator\.ssh scp id_dsa.pub [email protected]: <enter password> ssh [email protected] <enter password> cat id_dsa.pub >> .ssh/authorized_keys2 exit ssh [email protected] <no password prompt> </snipped> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/1a7c01cb1324$4c00c3a0$7a00a...@w2k3s02 ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
