废话开头:

之前参考这位同学的博客http://www.cnblogs.com/awy-blog/p/3447176.html,同时综合OpenStack的ubuntu的官方安装文档,在修改了一些小错误之后,成功地用三台普通的物理PC机搭了一个OpenStack的环境,各项服务、功能都测试了一遍,感觉还可以。不过后来,由于其中的一台物理机被别人拿走之后,于是乎没继续使用测试了,转而去研究代码了。

后来,由于某种需求,又要开重新搭建这个环境。没有够多的物理机,于是乎开始使用楼下的一台刀片服务器来完了,12核24线程、40多G的大内存,4块500G的硬盘,够给力了,跑三个虚拟机来搭OpenStack的环境也绰绰有余了。但是,搭完之后,问题就来了,发现无法向虚机注入密钥,也就是用ssh密钥登录虚机了。这对那些必须需要使用密钥登录的镜像来说还是有很大的不便。

下面开始步入正题:

在node4上面架设三个kvm的虚机,分别跑controller、network、compter,现在已经成功把openstack跑起来了,可以运行实例,neutron组网没问题,虚机内外网都能ping通,但是当我想用ssh密钥登录时发现:先前导入的密钥对,无法将公钥导入到虚机中,以至于没法实现密钥登录。
 

虚机起来后,查看日志/var/log/nova/nova-api.log :

2014-03-08 15:36:02.347 16855 INFO nova.metadata.wsgi.server [-] (16855) accepted ('192.168.122.3', 55466)

2014-03-08 15:36:02.349 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.350 16855 INFO nova.api.ec2 [-] 0.1089s 192.168.122.3 GET /2009-04-04/meta-data/public-hostname None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.350 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403len: 176 time: 0.0018518

2014-03-08 15:36:02.865 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.867 16855 INFO nova.api.ec2 [-] 0.1279s 192.168.122.3 GET /2009-04-04/meta-data/placement/availability-zone None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.868 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/placement/availability-zone HTTP/1.1" status: 403len: 176 time: 0.0024281

在dashboard的界面里面,查看虚机的日志中提示错误:

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 10.44. iid had '<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>
<h1>500 Internal Server Error</h1>
An unknown error has occurred. Please try your request again.<br /><br />

而当我登录虚拟,查看里面的~/.ssh/authorized_keys里面内容不是要注入的公钥,正是上面出错的html页面代码!

在虚机中运行curl检测如下:

$ curl -I http://169.254.169.254/2009-04-04/meta-data/instance-id

HTTP/1.1 500 Internal Server Error

Content-Type: text/html; charset=UTF-8

Content-Length: 0

Date: Sat, 08 Mar 2014 09:45:57 GMT

 
我知道应该是nova-api-metadata的问题, 但这个该怎么解决呢?
 
      开始,我也觉得是网络的问题,总感觉169.254.169.254很奇怪,后来一搜才知道是为了兼容 amazon 的 EC2 ,才把获取metadata的ip也写死成这个,不过在openstack里面,通过iptables映射成controller的ip并对应8775端口。从nova-api.log的日志分析,显然在computer的虚机10.50.50.2的请求,是已经被在controller的nova-api-metadata的服务获取到了。但是 “WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature”,这说明X-Instance-ID-Signature 验证不通过,导致metadata server 拒绝请求,从而引发了:10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403 len: 176 time: 0.0018518,即服务端返回403的错误代码,而在虚机中则得到了HTTP 500的错误响应。
 
    后来问题搞定了,当我去分别查找Network node 上面的nova/api/metadata/handler.py ,以及在网络节点的neutron/agent/metadata/agent.py 去比较如何处理X-Instance-ID-Signature的时候,发现如下:
 
         if resp.status == 200:
LOG.debug(str(resp))
return content
elif resp.status == 403:
msg = _(
'The remote metadata server responded with Forbidden. This'
'response usually occurs when shared secrets do not match.'
)
LOG.warn(msg)
return webob.exc.HTTPForbidden()
elif resp.status == 404:
return webob.exc.HTTPNotFound()
elif resp.status == 409:
return webob.exc.HTTPConflict()
elif resp.status == 500:
msg = _(
'Remote metadata server experienced an internal server error.'
)
LOG.warn(msg)
return webob.exc.HTTPInternalServerError(explanation=unicode(msg))
else:
raise Exception(_('Unexpected response code: %s') % resp.status)

显然提示403出错的代码,是因为“The remote metadata server responded with Forbidden. This response usually occurs when shared secrets do not match.”,即提示 share secrets 不匹配。这个我很早就注意到了,网上的提示的方法也是这么说的。我当时很确定地把nova.conf 的service_neutron_metadata_proxy 设为true,并且neutron_metadata_proxy_shared_secret 跟neutron里面的metadata_agent.ini一样都是helloOpenStack,这个是我反复检查过的。可是,让我万万没想到的是。。。。。。。
 
当我vim查看metadata_agent.ini的文件时,无意间看到一句comment:
 
# When proxying metadata requests, Neutron signs the Instance-ID header with a
# shared secret to prevent spoofing. You may select any string for a secret,
# but it must match here and in the configuration used by the Nova Metadata
# Server. NOTE: Nova uses a different key: neutron_metadata_proxy_shared_secret
 
 
我靠!nova.conf与metadata_agent.ini里面关于share secret 的字段名是不一样的!!!一个是neutron_metadata_proxy_shared_secret,而另一个却是metadata_proxy_shared_secret
 
    天杀的,好大一个坑。。。。。。。。。
    
 
关于metadata的注入流程分析,可以参考贤哥的两篇文章:

【OpenStack】metadata在OpenStack中的使用:

http://blog.csdn.net/lynn_kong/article/details/9115033

                           http://lingxiankong.github.io/blog/2014/03/25/metadata/
 
 
          
05-11 18:40