Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I need to automate the provisioning of a cloud instance (running Fedora 17) for which the following initial facts are true:

  • I have ssh-key based access to a remote user (cloud)
  • That user has password-free root access via sudo.

Manual configuration is as simple as logging in and running sudo su - and having at it, but I would like to fully automate this process. The trick is that the system defaults to having the requiretty option enabled for sudo, which means that an attempt to do something like this:

ssh remotehost sudo yum -y install puppet

Will fail:

sudo: sorry, you must have a tty to run sudo

I am working around this right now by first pushing over a small Python script that will run a command on a pseudoterminal:

import os
import sys
import errno
import subprocess

pid, master_fd = os.forkpty()

if pid == 0:
    # child process: now that we're attached to a
    # pty, run the given command.
    os.execvp(sys.argv[1], sys.argv[1:])
else:
    while True:
        try:
            data = os.read(master_fd, 1024)
        except OSError, detail:
            if detail.errno == errno.EIO:
                break

        if not data:
            break

        sys.stdout.write(data)

    os.wait()

Assuming that this is named pty, I can then run:

ssh remotehost ./pty sudo yum -y install puppet

This works fine, but I'm wondering if there are solutions already available that I haven't considered.

  • I would normally think about expect, but it's not installed by default on this system.
  • screen can do this in a pinch, but the best I came up with was:

    screen -dmS sudo somecommand
    

    ...which does work but eats the output.

Are there any other tools available that will allocate a pseudoterminal for me that are going to be generally available?

share|improve this question
    
Great question. I experimented a bit with screen a while back, but usually had to redirect the output elsewhere and cat it after the screen command had finished executing. The -t ssh option seems less hackish, though :) –  Adam Eberlin Oct 24 '12 at 22:45
add comment

2 Answers

up vote 4 down vote accepted

You want the -t option to ssh:

 -t      Force pseudo-tty allocation.  This can be used to execute
         arbitrary screen-based programs on a remote machine, which can be
         very useful, e.g. when implementing menu services.  Multiple -t
         options force tty allocation, even if ssh has no local tty.

You may need to use -tt if the script is going to be run non-interactively.

share|improve this answer
    
It was in fact the -tt I was missing. I'm calling ssh via pdsh, and the connections don't have a local pty. This really goes to reading comprehension on my part, I guess. Thanks for the pointer! –  larsks Oct 25 '12 at 3:28
add comment

Why don't you just comment out the requiretty-line in /etc/sudoers ?

share|improve this answer
1  
Because to do that I need root access via sudo...which I can't non-interactively until I can get root access via sudo :). As I said, it's certainly possible to take care of things manually; I'm just trying to automate the process. –  larsks Oct 24 '12 at 14:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.