Feb 202014
 

在Openstack上,如果你想实现迁移,resize,你都需要配置这个,就是让所有的计算节点,用nova的账号,使用密钥互相访问。

以前我的办法比较土,手工操作也很累,http://www.chenshake.com/of-work-installing-your-rdo/

所以我必须想一个办法来解决这个问题。我需要解决

  1. 我可以用密钥,无密码访问所有的计算节点
  2. 我可以批量复制文件夹到远程的计算节点上
  3. 运行远程的脚本,完成所有的设置

春节期间,我已经把所有的服务器,改成用密钥访问,就是从那台控制节点的机器,可以无密码访问其他机器。

我这里简单记录一下过程,大概的思路就是用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账号无密码计算节点访问”

  1. 陈老师:
    一直关注您的博客,我想问一个跟本文不相关的问题。openstack目前的版本提供了kvm下的虚拟机快照的功能了吗?我看kvm社区对于快照的支持一直没有加入到trunk里来,在网上也没找到相关的资料,所以想请教一下。

  2. 现在有op相关的Q群没 官方irc 卖呆的多 说话的少

  3. 陈老师您好,又来打扰您了。我想问一下,你用ESXi-5.5的虚拟机装过openstack吧?我现在用两台服务器安装ESXi-5.5后,再虚拟出4台机器,想再测试一次openstack,但是提示
    “INFO: Your CPU does not support KVM extensions
    KVM acceleration can NOT be used”
    您是否有解决办法?

  4. 我的服务器肯定支持虚拟化的,否则装不了ESXi-5.5。我按照网友的方法,修改了
    “/etc/vmware/config”配置文件
    vhv.allow = “TRUE”
    然后再修改虚拟机设置

    还是不行。

  5. 陈老师:
    您好,看到您的这篇文章我对密钥认证这个问题有个疑问——在企业当中,如果启用了密钥认证,那么密钥被别人恶意复制了,那么这台服务器岂不是很危险,相当于口令被人知道了,虽然可以重建密钥文件(相当于修改口令)来阻断,但是他的泄露程度还是要比口令来的容易,当然这种风险还是主要来自内部风险。
    想请教您,这个问题如果避免或者规避还是直接接受呢?

    • 其实是的。按道理,私钥是不允许放多个地方,这仅仅是为了演示,demo,简单处理。生产环境,肯定不能这样。

      • 陈老师,您好,这个问题其实是一个比较现实的问题,密码和密钥两种认证方式都是等同的,密码有窥视的危险,密钥有泄露的风险;这个风险的是接收风险还是生产环境就不能启用密钥认证呢?
        我做过实验,结果我记得是公钥放到那台服务器上,那么有私钥的一方就可以随意进入,但是把私钥从a服务器拿到b服务器好似就不可以了,因为公私钥是在a产生的,公钥的放置很关键,但是由于.ssh路径的权限必须是755,authorized_keys的权限是644, 这个对企业it管理来说没有办法规避的风险,但是由于业务需要,定时单/双向传输文件,是启用密钥认证安全呢,还是将密码配置到配置文件中,将配置文件加密安全呢?

  6. 您好,最近接触OpenStack,还不算上手,参考了您的几篇文章感觉获益匪浅,这里表示非常感谢。有个事儿想麻烦一下,博主有一篇2012年秋季OpenStack峰会总结的文章,里面的PPT分享微盘地址貌似已经没有了。我做的研究和里面IBM的一段演讲“Getting Physical: Using OpenStack to Provision and Manage Physical Servers, not just VMs”有关,想找一下这个PPT,能否麻烦您帮我看看,还有没有原文件?多谢!

 Leave a Reply

(required)

(required)