Feb 202014
在Openstack上，如果你想实现迁移，resize，你都需要配置这个，就是让所有的计算节点，用nova的账号，使用密钥互相访问。
以前我的办法比较土，手工操作也很累，http://www.chenshake.com/of-work-installing-your-rdo/
所以我必须想一个办法来解决这个问题。我需要解决
- 我可以用密钥，无密码访问所有的计算节点
- 我可以批量复制文件夹到远程的计算节点上
- 运行远程的脚本，完成所有的设置
春节期间，我已经把所有的服务器，改成用密钥访问，就是从那台控制节点的机器，可以无密码访问其他机器。
我这里简单记录一下过程,大概的思路就是用root的用户的公钥,私钥,都复制到nova的账号底下。我们需要把密钥可以批量复制到所有的计算节点，并且运行一个脚本，实现所有的修改。
创建一个nova的文件夹，把root的密钥都复制到里面。
cd mkdir nova cp -r /root/.ssh /root/nova/ssh
创建 /root/nova/nova.sh
#!/bin/sh
usermod -s /bin/bash nova
cp -r ./ssh /var/lib/nova/.ssh
chown -R nova:nova /var/lib/nova/.ssh
crudini --set /etc/nova/nova.conf DEFAULT libvirt_inject_password true
service openstack-nova-compute restart
脚本的内容可以自己添加，根据自己的需求，修改nova.conf文件。
在root目录下，创建一个计算节点的列表。
# cat host_list 172.18.1.20 172.18.1.21
创建批量复制脚本, distrun.sh
就是把nova的文件夹复制到所有的计算节点上，并且运行nova文件夹下的nova.sh 脚本。
#!/bin/sh input_list=$1 for i in `cat $input_list` do #echo "this is a test" >> /root/sendtoremote.txt ssh -n $i "hostname" scp -r /root/nova root@$i:/root/ ssh -n $i "cd /root/nova/ && chmod +x nova.sh && ./nova.sh" done
运行脚本
nohup sh -x distrun.sh host_list 1>out.txt 2>err.txt &
或者
chmod +x distrun.sh ./distrun.sh host_list
运行完，基本就ok。
9 Responses to “nova账号无密码计算节点访问”
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
陈老师：
一直关注您的博客，我想问一个跟本文不相关的问题。openstack目前的版本提供了kvm下的虚拟机快照的功能了吗？我看kvm社区对于快照的支持一直没有加入到trunk里来，在网上也没找到相关的资料，所以想请教一下。
如果你是qcow2格式，是支持快照的，如果raw，不支持。
现在有op相关的Q群没 官方irc 卖呆的多 说话的少
陈老师您好，又来打扰您了。我想问一下，你用ESXi-5.5的虚拟机装过openstack吧？我现在用两台服务器安装ESXi-5.5后，再虚拟出4台机器，想再测试一次openstack，但是提示
“INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used”
您是否有解决办法？
我的服务器肯定支持虚拟化的，否则装不了ESXi-5.5。我按照网友的方法，修改了
“/etc/vmware/config”配置文件
vhv.allow = “TRUE”
然后再修改虚拟机设置
还是不行。
陈老师：
您好，看到您的这篇文章我对密钥认证这个问题有个疑问——在企业当中，如果启用了密钥认证，那么密钥被别人恶意复制了，那么这台服务器岂不是很危险，相当于口令被人知道了，虽然可以重建密钥文件（相当于修改口令）来阻断，但是他的泄露程度还是要比口令来的容易，当然这种风险还是主要来自内部风险。
想请教您，这个问题如果避免或者规避还是直接接受呢？
其实是的。按道理，私钥是不允许放多个地方，这仅仅是为了演示，demo，简单处理。生产环境，肯定不能这样。
陈老师，您好，这个问题其实是一个比较现实的问题，密码和密钥两种认证方式都是等同的，密码有窥视的危险，密钥有泄露的风险；这个风险的是接收风险还是生产环境就不能启用密钥认证呢？
我做过实验，结果我记得是公钥放到那台服务器上，那么有私钥的一方就可以随意进入，但是把私钥从a服务器拿到b服务器好似就不可以了，因为公私钥是在a产生的，公钥的放置很关键，但是由于.ssh路径的权限必须是755，authorized_keys的权限是644， 这个对企业it管理来说没有办法规避的风险，但是由于业务需要，定时单/双向传输文件，是启用密钥认证安全呢，还是将密码配置到配置文件中，将配置文件加密安全呢？
您好，最近接触OpenStack，还不算上手，参考了您的几篇文章感觉获益匪浅，这里表示非常感谢。有个事儿想麻烦一下，博主有一篇2012年秋季OpenStack峰会总结的文章，里面的PPT分享微盘地址貌似已经没有了。我做的研究和里面IBM的一段演讲“Getting Physical: Using OpenStack to Provision and Manage Physical Servers, not just VMs”有关，想找一下这个PPT，能否麻烦您帮我看看，还有没有原文件？多谢！