配置前的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-ing并运行该命令导致'权限被拒绝'(显然,非root用户试图在根目录中创建一个目录).我尝试以root身份进行ssh-ing,但这似乎是不好的做法.(而且亚马逊不喜欢它)如何将文件夹更改为与vagrant-aws一起使用？我似乎找不到那个设置.谢谢!

Answer 1

很可能你遇到了已知的vagrant-aws问题#72:使用EC2 Amazon Linux映像失败.

编辑3(2014年2月): Vagrant 1.4.0(2013年12月发布)及更高版本现在支持布尔配置参数config.ssh.pty.将参数设置为true以强制Vagrant使用PTY进行配置.Vagrant创建者Mitchell Hashimoto 指出你不能设置config.ssh.pty全局配置,你必须直接在节点配置上设置它.

此新设置应该可以解决问题,您不再需要下面列出的解决方法.(但请注意,我还没有亲自测试过.)有关详细信息,请参阅Vagrant的CHANGELOG - 遗憾的config.ssh.pty是,该选项尚未在Vagrant文​​档中的SSH设置中记录.

编辑2:坏消息.看起来好像甚至boothook不会!requiretty比Vagrant尝试rsync 更快"运行(更新/etc/sudoers.d/ )".在我今天的测试中,我开始在运行时再次看到零星的"mkdir -p/vagrant"错误vagrant up --no-provision.所以我们回到之前的点,其中最可靠的修复似乎是一个自定义的AMI图像,已经包含应用的补丁/etc/sudoers.d.

编辑:看起来我找到了一种更可靠的方法来解决问题.使用boothook执行修复.我手动确认boothook在Vagrant的rsync阶段开始之前执行了作为a传递的脚本.到目前为止,它一直在为我工作,我不需要创建自定义AMI图像.

额外提示:如果你也依赖cloud-config,你可以创建一个Mime多部件档案来组合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:最可靠的解决方案是"修补"亚马逊Linux AMI图像的库存,保存它,然后使用自定义的AMI图像Vagrantfile.请参阅下文了解详情.

背景

在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"

最重要的是,这将使操作系统配置为不需要用户tty ec2-user,这似乎是问题的根源.我认为/ 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

然后,您必须使用此自定义AMI图像Vagrantfile而不是亚马逊股票.显而易见的缺点是,您不再使用亚马逊AMI图像 - 这是否与您有关,取决于您的要求.

我尝试过但没有成功

为了记录:我也试图通过一cloud-config到aws.user_data,其中包括一个bootcmd设置!requiretty相同的方式与上面嵌入shell脚本.根据cloud-init文档bootcmd,在EC2实例的启动周期中"非常早"运行 - 这个想法是bootcmd指令将比Vagrant更早地运行并尝试运行其rsync阶段.但不幸的是,我发现当前亚马逊的Linux AMI bootcmd的过期cloud-init版本没有实现该功能(例如ami-05355a6c的cloud-init为0.5.15-69.amzn1,但bootcmd仅在0.6.1中引入).