Thanks, Lee. I tried both default_run_options[:pty] = true and default_run_options[:pty] = false
executing a cap deploy:update after each change, and I saw no change in the behavior as I described it initially. However, with my deploy.rb still saying false for the pty option (just because I didn't think to remove it before the next thing I tried), I logged in to the web server machine (ssh'd over from my development machine) and simply did an svn info to the repository. I was asked again for the realm password, and again whether or not the password could be stored in clear text. I answered yes and was given the normal svn info stuff. Then I logged out and did another cap deploy:update and it worked! My theory was that the svn.simple file wasn't set up properly, and although I had already gone through this step (attempt svn info from the web server back to the svn server) before, it wasn't with the pty option clearly stated. On my subversion server $ svn --version svn, version 1.6.5 (r388866) $ svnserve --version svnserve, version 1.6.5 (r38866) On the web server I'm deploying to: $ svn --version svn, version 1.6.5 (r388866) $ svnserve --version svnserve, version 1.6.5 (r38866) On my development client: $ svn --version svn, version 1.6.5 (r388866) $ svnserve --version svnserve, version 1.6.5 (r38866) The capistrano gem version on all three machines is 2.5.19 The rails version on all three is 3.0.3 The production version of ruby on all three machines is 1.8.7 though in development I use rvm and several rubies. Thanks for your pointers. On Jan 22, 1:18 pm, Lee Hambley <[email protected]> wrote: > Hi Jim, > > It depends largely on whether or not you asked Capistrano to request a pty > (pseudo terminal), if you did (options[:pty] = true) then some assumptions > are made on the server-side about you being able to respond to prompts… some > badly behaved software might even ask you for a prompt without checking if > there's a terminal available (I can't mention if Subversion fits into this > category.) > > It might have missed your reading, but again logging-in has a number of > implications, not only if you log-in to a real SSH session, will you assign > a PTY, but it will also have access to your PATH, and other environmental > settings, and will probably run your dotfiles… which are a number of things > that won't happen with Cap. > > Come back to me, and see if any / all of this helps… also software versions > can be significant, please post all (if relevant) > > - Lee > > On 22 January 2011 16:19, Jim <[email protected]> wrote: > > > > > This is my first capistrano deployment effort, so I think I've done > > due diligence in researching what I'm seeing, but I will apologize in > > advance if I missed this somewhere else. > > > I'm trying to deploy a Rails 3 application from development on my Mac > > OS X 10.6.6 client to my Mac OS X 10.6.6 server, but the plaintext > > password nag in subversion seems to persist no matter what I do. > > > my cap deploy:update task starts, begins the deploy:update_code step, > > executes locally the svn info command to get the head revision number > > and then attempts to execute the checkout command on my server. > > > At this point I get the svn password prompt: > > ** [www.myhost.com:: err] Authentication realm: <svn://my.myhost.com: > > 3690> myApp > > ** [www.myhost.com:: err] Password for 'jim': > > Password: > > > As soon as I enter it I get the nag about storing plaintext passwords > > and I'm asked: > > ** Store password unencrypted (yes/no)? > > ** [www.myhost.com:: err] Please type 'yes' or 'no': > > > Now I'm stuck because capistrano doesn't appear to be sending my > > response back... at least by hitting control-t I can see that ruby is > > awaiting a response. > > > Things I've tried so far: > > 1) in my user account on the server I've configured ~/.subversion/ > > servers to > > store-plaintext-passwords = no > > 2) similarly, > > store-plaintext-passwords = yes > > 3) in ~/.subversion/config I've set the token > > password-stores = keychain > > and performed a couple of svn operations by hand (i.e. not capistrano- > > invoked) to ensure there is a keychain entry for my svn repository. > > 4) in deploy.rb I added > > set :svn_password, "mypassword" > > > To be sure, while logged in to my account on the server I'm not > > getting the plaintext password nag from subversion, only through > > capistrano. > > > Since I'm just starting, my deploy.rb file is devoid of any tasks or > > anything beyond what I understand to be the basics: > > set :application, "myapp" > > set :repository, "svn://my.myhost.com" > > set :svn_password, "mypassword" > > set :scm, :subversion > > role :web, "www.myhost.com" > > role :app, "www.myhost.com" > > role :db, "www.myhost.com", :primary => true > > set :deploy_to, "/Library/WebServer/Rails/myapp" > > set :use_sudo, false > > > That's it. > > > I'm not necessarily adamant about using the keychain, but it would > > seem to be the most secure method. What I really wanted to do at this > > point was just get deployment going so I can see if the tasks that do > > that are configured properly -- but I'm stopped cold by this problem! > > > So what did I miss in all my reading and searching and experimenting? > > > -- > > * You received this message because you are subscribed to the Google Groups > > "Capistrano" group. > > * To post to this group, send email to [email protected] > > * To unsubscribe from this group, send email to > > [email protected]<capistrano%2Bunsubscribe@googlegrou > > ps.com>For more options, visit this group at > >http://groups.google.com/group/capistrano?hl=en -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
