Nova 無法向虛機注入密鑰


 

廢話開頭:

 

   之前參考這位同學的博客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/
 
 
          


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM