amazon-web-services - 设置前出现Vagrant 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-sing并运行该命令会产生“权限被拒绝”（显然，非root用户正在尝试在根目录中创建目录）。我尝试以root身份使用ssh-ing，但这似乎是一种不好的做法。 （而且亚马逊不喜欢）如何更改要与vagrant-aws同步的文件夹？我似乎找不到该设置。谢谢！

Answer 1

您很可能遇到了已知的无业游民的问题#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执行修复。我手动确认在Vagrant的rsync阶段开始之前，已执行作为boothook传递的脚本。到目前为止，它对我来说一直可靠地工作，并且我不需要创建自定义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，这似乎是问题的根源。我认为实际的修补程序不需要额外安装 puppet软件包（尽管Vagrant以后可能会使用Puppet来配置计算机，具体取决于您如何配置Vagrant）。

我对上述解决方法的经验

我已经尝试过这种解决方法，但Vagrant仍然偶尔会因相同的错误而失败。这可能是一种“竞争条件”，其中Vagrant恰好以高于cloud-init（这是 aws.user_data传递信息的目标）可以为Vagrant在计算机上为＃72准备变通办法的方式运行其rsync阶段。如果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 AMI映像。明显的缺点是您不再使用库存的Amazon AMI映像-是否需要担心取决于您的要求。

我尝试过但没有解决的问题

作为记录：我还尝试将 cloud-config传递给 aws.user_data，其中包括 bootcmd来设置 !requiretty，方法与上述嵌入式shell脚本相同。根据cloud-init docs的说法， bootcmd在EC2实例的启动周期中“非常早”运行-想法是 bootcmd指令将比Vagrant尝试运行其rsync阶段更早地运行。但不幸的是，我发现当前亚马逊Linux AMI的过时 bootcmd版本中未实现 cloud-init功能（例如ami-05355a6c具有cloud-init 0.5.15-69.amzn1但 bootcmd was only introduced in 0.6.1）。