配置前出现Rsync错误

Question

所以我在vagrant-aws插件上经历了一些冒险，现在我被文件夹同步的问题卡住了。这是配置机器所必需的，这是最终目标。但是，在我的机器上运行vagrant provision会产生以下结果

[root@vagrant-puppet-minimal vagrant]# vagrant provision
[default] Rsyncing folder: /home/vagrant/ => /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed! 
mkdir -p '/vagrant'

我几乎可以肯定，这个错误是因为手动执行ssh并运行该命令会导致“权限被拒绝”(显然，非root用户正在尝试在根目录中创建一个目录)。我尝试以root用户身份使用ssh-ing，但这似乎是一种糟糕的做法。(亚马逊不喜欢它)我如何才能将文件夹更改为与vagrant-aws同步？我似乎找不到它的设置。谢谢!

Answer 1

您很可能遇到了已知的流浪者-aws issue #72: Failing with EC2 Amazon Linux Images。

编辑3(2014年2月)： Vagrant 1.4.0 (2013年12月发布)及更高版本现在支持布尔配置参数config.ssh.pty。将该参数设置为true可强制Vagrant使用PTY进行配置。流浪汉创建者Mitchell Hashimoto points out告诉我们，您不能在全局配置上设置config.ssh.pty，必须直接在节点配置上设置。

这个新的设置应该可以解决这个问题，并且您不再需要下面列出的解决方法。(但请注意，我自己还没有测试过它。)有关详细信息，请参阅Vagrant's CHANGELOG --不幸的是，在Vagrant文档中的SSH Settings下还没有记录config.ssh.pty选项。

编辑2:坏消息。看起来似乎即使是boothook也不会比Vagrant尝试的rsync“更快”地运行(为!requiretty更新/etc/sudoers.d/ )。在今天的测试中，我开始在运行vagrant up --no-provision时再次看到零星的"mkdir -p /vagrant“错误。因此，我们回到了前一点，在那里最可靠的修复似乎是自定义AMI镜像，它已经包含了对/etc/sudoers.d应用的补丁。

编辑：看起来我找到了一个更可靠的方法来解决这个问题。使用boothook执行修复。我手动确认作为boothook传递的脚本在Vagrant的rsync阶段开始之前执行。到目前为止，它对我来说是可靠的，我不需要创建一个自定义的AMI镜像。

额外提示:如果您也依赖于cloud-config，那么可以创建一个Mime Multi Part Archive来组合boothook和cloud-config。您可以从GitHub获得最新版本的write-mime-multipart助手脚本。

使用草图：

$ cd /tmp
$ wget https://raw.github.com/lovelysystems/cloud-init/master/tools/write-mime-multipart
$ chmod +x write-mime-multipart
$ cat boothook.sh
#!/bin/bash
SUDOERS_FILE=/etc/sudoers.d/999-vagrant-cloud-init-requiretty
echo "Defaults:ec2-user !requiretty" > $SUDOERS_FILE
echo "Defaults:root !requiretty" >> $SUDOERS_FILE
chmod 440 $SUDOERS_FILE

$ cat cloud-config
#cloud-config

packages:
  - puppet
  - git
  - python-boto

$ ./write-mime-multipart boothook.sh cloud-config > combined.txt

然后，您可以将'combined.txt‘的内容传递给aws.user_data，例如，通过：

aws.user_data = File.read("/tmp/combined.txt")

很抱歉之前没有提到这一点，但我自己现在确实在解决这个问题。:)

原始答案(参见上面的更好的方法)

TL;DR：最可靠的修复方法是“修补”一个Amazon Linux AMI镜像，保存它，然后在您的Vagrantfile中使用定制的AMI镜像。有关详细信息，请参见下文。

背景

在https://github.com/mitchellh/vagrant-aws/pull/70/files上描述了一个潜在的解决方法(并在上面的错误报告中进行了链接)。简而言之，将以下代码添加到Vagrantfile中

aws.user_data = "#!/bin/bash\necho 'Defaults:ec2-user !requiretty' > /etc/sudoers.d/999-vagrant-cloud-init-requiretty && chmod 440 /etc/sudoers.d/999-vagrant-cloud-init-requiretty\nyum install -y puppet\n"

最重要的是，这将把操作系统配置为不需要用户ec2-user的tty，这似乎是问题的根源。I/认为/实际修复不需要额外安装puppet包(尽管Vagrant稍后可能会使用Puppet来配置机器，这取决于您是如何配置Vagrant的)。

我使用所描述的解决方法的经验

我已经尝试过这种解决方法，但Vagrant仍然偶尔会失败，并出现相同的错误。这可能是一个“竞争条件”，Vagrant碰巧运行其rsync阶段的速度比cloud-init ( aws.user_data正在向其传递信息)可以在机器上为Vagrant准备#72的变通方法。如果Vagrant更快，你会看到同样的错误；如果cloud-init更快，它就能工作。

什么是可行的(但需要你方付出更多的努力)

确定有效的方法是在一个现货Amazon Linux AMI镜像上运行该命令，然后将修改后的镜像(=创建一个镜像快照)保存为您的自定义AMI镜像。

# Start an EC2 instance with a stock Amazon Linux AMI image and ssh-connect to it
$ sudo su - root
$ echo 'Defaults:ec2-user !requiretty' > /etc/sudoers.d/999-vagrant-cloud-init-requiretty
$ chmod 440 /etc/sudoers.d/999-vagrant-cloud-init-requiretty

# Note: Installing puppet is mentioned in the #72 bug report but I /think/ you do not need it
#       to fix the described Vagrant problem.
$ yum install -y puppet

然后，您必须在您的Vagrantfile中使用此自定义AMI镜像，而不是现有的Amazon镜像。明显的缺点是，您不再使用现成的Amazon AMI镜像--您是否需要考虑这一点取决于您的需求。

我试过但没有成功

需要说明的是:我还尝试将一个cloud-config传递给aws.user_data，其中包含一个设置!requiretty的bootcmd，方法与上面的嵌入式shell脚本相同。根据cloud-init文档，bootcmd在EC2实例的启动周期中“非常早”运行--其想法是bootcmd指令将在Vagrant尝试运行其rsync阶段之前运行。但不幸的是，我发现当前亚马逊的Linux的过时cloud-init版本并没有实现云功能(例如，ami-05355a6c有bootcmd -init 0.5.15-69.amzn1，但有bootcmd was only introduced in 0.6.1)。