bash 之 <

注意，这个脚本里面的cat，这里很容易写作echo的，因为php中就是用的echo； 我们很容易将这种语法视为写复杂字符串的一种方法，而在shell中，这不是一个复杂的字符串，而是把这些内容作为命令的标准输入提供给命令的，而不是命令的参数：

知道了原理之后，就再也不用担心写错了

以发展的眼光看问题

时移世易，变法宜矣

上胡不法先王之法，非不贤也，为其不可得而法。先王之法，经乎上世而来者也，人或益之，人或损之，胡可得而法？虽人弗损益，犹若不可得而法。
凡先王之法，有要於时也，时不与法俱至。法虽今而至，犹若不可法。故释先王之成法，而法其所以为法。先王之所以为法者何也？先王之所以为法者人也。而己亦人也，故察己则可以知人，察今则可以知古，古今一也，人与我同耳。有道之士，贵以近知远，以今知古，以益所见，知所不见。故审堂下之阴，而知日月之行、阴阳之变；见瓶水之冰，而知天下之寒、鱼鳖之藏也；尝一脟肉，而知一镬之味、一鼎之调。

http://blog.sina.cn/dpool/blog/s/blog_5d245fe70102w9j9.html

openstack 命令行之 安全组

列出所有安全组：

 

列出所有名叫default的安全组的ID：

 

列出指定安全组下的所有规则： （–long 显示每条规则的方向，默认不显示方向）

可以通过–ingress   –egress  只显示指定方向上的规则； 通过 –protocol 显示指定协议相关的规则

 

实际应用：

检查是否所有的“default” 安全组都设置了允许所有tcp、udp都可以主动外出的规则：

结果输出：

如果输出了tcp和udp就意味着是正确的

 

添加安全组规则：

允许所有tcp主动外出访问：

 

ssh-copy-id 之后ssh还是提示输入密码的问题

问题： 如题。

现场情况：

  1. 我~/.ssh/下有多个秘钥
  2. 配置了 .ssh/config 文件，不同类型的机器使用不同的秘钥，也有一些机器使用默认的秘钥

问题原因：

  1. ssh-copy-id 默认使用的秘钥并不是 id_rsa.pub，而是最新修改过的秘钥：
  2. ssh 命令默认使用的秘钥是 id_rsa.pub
  3. 所以，ssh-copy-id 和 ssh 默认不同的秘钥时，就会出现上述问题
  4. 说明：
    1. ssh-copy-id 时，会提示使用的秘钥是哪个的：
    2. 可以通过 -i 选项来指定ssh-copy-id来使用哪个秘钥：

openstack 之 计算节点名字

如下图： 虚拟机管理器和计算主机中显示的主机的名字不同，为什么呢？

 

说明：

虚拟机管理器说的是hypervisor，具体来讲就是libvirtd

主机说的是虚拟机管理器所在的宿主机，就是我们所谓的计算节点

二者的信息都是记录在nova.compute_nodes 表中的，二者都没有唯一约束；

当然，host是不会重复的；特殊情况下hypervisor_hostname 重复是有可能的； 从dashboard来看，节点资源是hypervisor的，而不是host的。

而且也可以存在一个host上有多个虚拟机管理器的情况，一个nova-compute接到任务后，可以通过不同的虚拟机管理器来创建虚拟机

 

分析：

不同计算节点上使用相同hypervisor_hostname时，hypervisor将拥有了多个机器的资源，那么虚拟机调度时参考hypervisor_hostname的资源的话，虚拟机分配的任务最终会被分配到哪个host上呢？毕竟不同host上都有nova-compute进程的； 另，上报资源时使用的是node的uuid还是host还是hypervisor_hostname？

node的uuid又是如何生成的呢？

hypervisor_hostname 是如何获取到的呢？hypervisor_hostname是不是第一次注册的时候写入后来就不再修改了呢？

主机资源是记录在 nova_api.resource_providers 表中的：

当然，只有nova.compute_nodes 表中记录的uuid才是有效的resource_providers，才会被dashboard显示

 

为什么node节点的hostname已经修改了，虚拟机管理器中显示的还是以前的名字？

nova-compute.log 中会有错误信息：

 

问题： 谁和谁不一致？重启谁？

解决办法：

比较： hostname 和virsh hostname的结果：

二者是不同的，前者的信息是从libvirtd中获取到的，也就是说，libvirtd中显示的主机名和当前的主机名不一致，需要重启libvirtd， 相关逻辑：

 

 

问题：

  1. 重启libvirtd需要先关闭所有虚拟机吗？
    答案： 不需要的，直接重启就行
  2. 虽然我重启了libvirtd，但是virsh hostname 还是 和 hostname不一样，为什么？
    答案： 因为我在/etc/resolv.conf 中配置了search i.beebank.com, libvirtd会自动suffix上search domain的
  3. 虽然现在virsh hostname 和hostname一致了，但是dashboard中看到的还是原来的，为什么？
    答案： 重启一下openstack-nova-compute

 

总结：

  1. 确认一下 /etc/resolv.conf  的配置
  2. systemctl restart libvirtd && systemctl restart openstack-nova-compute

注意：

  1. 修改了libvirtd的hostname之后，需要去数据库中手动修改相关虚拟机（nova.instances表中）的hypervisor_hostname，否则，就找不到这些机器的hypervisor了，而新的hypervisor下也是没有虚拟机的

 

 

PHP 并发执行命令之multi_cmd

代码功能：

同时执行多条命令，花费时间接近于最长那条命令的时间，而不是每条命令执行的时间和。

 

当 git 遇上 ansible

在配置了ansible的机器上启用了ControlPath配置： (这样效率会高一些)

 

然而，我还想在这个机器上使用ssh协议的git，这样不用每次都输入密码，然而，我不想使用默认的ssh key，于是在 ~/.ssh/config 中添加如下配置：

问题来了，如果没有Host * 的配置，git是好使的，有了Host * 的配置就不好使了，测试发现，是因为git不喜欢ControlPath， 然而，我google了一大圈，找不到unset掉ControlPath的方法，只好采用如下方式：

 

参考：

https://deepzz.com/post/how-to-setup-ssh-config.html

Docker容器中 man 提示 ‘No manual entry for man’

现象：

自从使用了docker容器，在容器中yum安装的软件就怎么着也man不了，man的时候就提示：

通过rpm查看软件包中是否包含man文件，确实包含； 使用rpm -V 也检查不到rpm包损坏； 实际上，man文件是不存在的。

原因：

  1. 我们使用的docker镜像已经被官方精简过了，把所有已安装软件的man页都删除了，这样镜像可以更小
  2. docker镜像中的/etc/yum.conf 也被刻意处理了一下，里面有个tsflags的选项，配置了nodocs，这样的话，新安装的软件也会被自动剔掉man文件（估计rpm知道man文件是被故意删掉的，所以也不报错）

解决办法：

  • /etc/yum.conf 中注释掉：
  • 卸载掉相关软件，重新yum安装

 

注： 上述情况是把docker容器当虚拟机使用的，并不太在乎镜像的大小

 

qemu-kvm 问题

guest内部显示内存充裕：

 

宿主机内存也充裕：

 

guest 对应的qemu-kvm进程在不停地将内存中的数据交换到swap中：

 

还有相同问题的另一个实例：

宿主机有足够的内存，qemu-kvm占用5.3G的swap，只使用566MB的内存，为什么？

guest内部的内存使用情况如下：

 

分析：

我们可能看见guest中看到的已用内存小于kvm进程的rss， 因为kvm进程的内存不仅包含提供给guest使用的内存，也包含自身其他需要的内存。

我们也可能看见guest中看到的已用内存大于kvm进程的rss，因为guest看到的内存未必是真正的内存，很可能早已被宿主机给交换到swap中去了，这就是我们上面看到的情况；guest刚刚起来的时候，并没有直接分配自己可以使用的最大内存，但是，可能某一个时刻一下子占用了90%的内存，当内存下降到10%的时候，80%的内存并没有还给宿主机，而是闲着，但是，宿主机永远不知道这80%的内存是在闲着的，唯一知道的就是好长时间没有访问了，于是，宿主机可能就会将这部分（不活跃的）内存交换到swap中去；等到guest想用内存的时候，其实访问的并不是内存，而是宿主机上的swap； 疑问： 随着guest中这80%的内存的频繁使用，会使得guest的真实内存变多而swap变少吗？应该会的

 

场景1： 大内存的kvm（16GB），里面只有一个使用很少内存（200MB）的小程序，不断地从外部下载文件，写入到磁盘中，结果就是： 下载过的文件都会被尽量缓存到内存中，16GB的内存大部分用于cache了，而且下载过的文件基本不会再被使用，于是，这部分内存就是in-active的了，于是，表现在宿主机上，这部分内存就会被尽力swap到磁盘上，当宿主机的swap被用尽时，其他进程想swap却很为难：

guest：

宿主机上：

宿主机上的kvm进程的RES远大于guest中内存的used，因为宿主机上的swap已用尽，如果添加更多的swap的话，会继续有更多的RES迁移到swap中去。

 

解决办法：

  1. guest本没必要使用16GB内存，给2GB就可以了； （尽管如此，也会有不必要的cache存在）
  2. guest中可以定期地drop cache，避免cache占用太大; 理论上来讲，一旦guest有大量的cache占用了内存，即使drop cache了，宿主机上也不会释放这部分内存（或swap），因为宿主机根本不知道这部分内存是不再使用了的；（当然，可以通过别的方式真正意义上回收这部分内存），如下：

    guest中drop cache后，buff/cache使用1.2G，宿主机上的RES、swap依然保持不变; 其实，不仅drop cache不能影响宿主机分配给guest的内存大小，reboot guest都不会影响宿主机分配给guest的内存大小的，因为reboot guest是热引导，kvm进程还是原来的进程，宿主机也不知道里面发生了重启的动作，所以，分配给kvm进程的资源也不会有变化

 

参考资料：

https://searchservervirtualization.techtarget.com/tip/Memory-swap-strategies-for-KVM