I did try a search on the mailing list and didn't see anything that looked like the same issue. I didn't run the test with Capistrano because I found an easier way to fix it: comment out the Defaults requiretty line in your sudoers file. That only exists to prevent ssh hostname sudo <cmd> because it will echo the sudo password to the screen, so anyone with you could see it. Since fabric is entering the sudo password (and not echoing it to the screen), this isn't really an issue.
The Defaults requiretty is off by default on most distributions, but apparently RHEL5 (and CentOS 5) have it on. Since it is off by default on most distributions, and easily disabled on the others, it isn't worth the problems that Christian mentioned. Thanks for your help! On Thu, Feb 12, 2009 at 6:52 AM, Christian Vest Hansen <[email protected] > wrote: > If we are required to open a shell session, rather than a simple > "command" (or what it's called) session to the SSH server, then we run > into issues of determining whether the commands we execute complete > successfully or not. > > The SSH protocol allow us to get the exit code back from any command > we run, and we use this to tell whether the commands we run are > successful or not. But when we open a shell session, this exit code > will always be that of the shell, and not whatever command we executed > through the shell. Also, I don't know of a stable way of telling which > shell we actually get, when we open such a session. > > On Thu, Feb 12, 2009 at 12:44 AM, Jeff Forcier <[email protected]> > wrote: > > I recall this coming up before, but not the final resolution. Might > > want to try searching the list archives in case I'm not misremembering > > :) > > > > Have you confirmed that this works with Capistrano and its tty option? > > Alternately, try doing "ssh my_rhel_server -t sudo some_command", > > which AFAIK would emulate the same behavior (forcing a pseudo-tty). > > > > I'm not positive that the tty-related option will actually work -- > > given that the sudoers manpage says "a real tty" and I'm not sure what > > exactly they mean by that -- but a quick Google seems to imply that it > > will. In that case, yes, we can likely add an argument/option/whatever > > to enable that aspect of the protocol when desired. > > > > About to embark on a potential rewrite of our SSH code to use a > > different library, but once that settles out either way, it should be > > pretty simple to put such a change in place. > > > > Best, > > Jeff > > > > On Wed, Feb 11, 2009 at 6:21 PM, Alex Robbins > > <[email protected]> wrote: > >> Thanks for the quick answer to the last question. > >> This time the issue is running sudo on the remote hosts. I get this > error: > >> sudo: sorry, you must have a tty to run sudo > >> > >> I know that I can take requiretty out of the sudoers file, but is that a > >> security issue? Some google searching showed that capistrano has an > option > >> to make tty on connection. Is that an idea under consideration? > >> (Running RHEL5.) > >> Thanks, > >> Alex > >> _______________________________________________ > >> Fab-user mailing list > >> [email protected] > >> http://lists.nongnu.org/mailman/listinfo/fab-user > >> > >> > > > > > > _______________________________________________ > > Fab-user mailing list > > [email protected] > > http://lists.nongnu.org/mailman/listinfo/fab-user > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. >
_______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
