上一篇提到：

刪除后面的用戶驗(yàn)證部分，錯(cuò)誤還是同樣發(fā)生。說(shuō)明還未進(jìn)行用戶驗(yàn)證，在http://localhost:8089/cli這個(gè)端口訪問(wèn)時(shí)出問(wèn)題，現(xiàn)在還在排查。

命令是這樣的：

java -jar jenkins-cli.jar -s http://localhost:8080/ --username XXX --password XXX

接下來(lái)，猜想未驗(yàn)證用戶的原因可能是jar包本身沒(méi)有--username和--password參數(shù)，導(dǎo)致后面的部分被忽略，于是更新jar包，果然在新jar包在java7下無(wú)法運(yùn)行，然后升級(jí)java7->java8，成功。

排查問(wèn)題的關(guān)鍵在于刪除username參數(shù)同樣得到403錯(cuò)誤，說(shuō)明后面部分未被驗(yàn)證。

這個(gè)問(wèn)題解決，接下來(lái)需要使用非UI形式創(chuàng)建jenkins-job，考慮最簡(jiǎn)單的配置文件方法，即寫好需要的config.xml文件，然后復(fù)制到對(duì)應(yīng)的jenkins_home文件夾下，jenkins啟動(dòng)后會(huì)自行讀取生成job。

docker cp指令拷貝文件到container，但是發(fā)現(xiàn)拷貝進(jìn)入container的文件所有者和群組變成了root:root，google后發(fā)現(xiàn)jenkins2確實(shí)會(huì)將拷入文件所有者和群組默認(rèn)更改，那么在保證安全，不轉(zhuǎn)root用戶的條件下，無(wú)法使用docker cp完成工作。

咨詢林老師后我們采用curl請(qǐng)求的方式發(fā)送config文件：

curl -X POST http://192.168.99.100:8088/createItem?name\=TestCreate --user twars:twars --data-binary "@config.xml" -H "Content-Type:text/xml"

發(fā)現(xiàn)jenkins2下權(quán)限不足，google后發(fā)現(xiàn)：

Jenkins by default has CSRF Protection enabled which prevents one-click attacks.you need to obtain the crumb from/crumbIssuer/api/xml，using your credentials and include it into your request.

需要先得到crumb token然后進(jìn)行請(qǐng)求，但是所有請(qǐng)求都是如此，所以無(wú)法先用請(qǐng)求的方式獲取crumb token，于是此路不通。

最后還是采用volume映射的方式，pair成功，但是在我自己的云上，因?yàn)槟J(rèn)使用root權(quán)限創(chuàng)建docker，所以文件映射后還是出現(xiàn)權(quán)限問(wèn)題，接下的工作就是創(chuàng)建普通用戶再走一遍。