关于vagrant

使用vagrant启动的虚拟机总是有一块特殊的网卡，ip地址为10.0.2.15， 这是个什么东东？

为了便于和虚拟机通信以及虚拟机自动上网等原因，vagrant自动为虚拟机创建了一个nat类型的网卡，所有虚拟机上该网卡的ip地址是一样的，所以只存在这一块儿网卡的时候，虚拟机之间没法通信。

vagrant 宿主机和虚拟机之间通信一般采用ssh或winrm，当将本机的2205端口nat到某虚拟机的22端口时，2205端口实际上是有虚拟机进程virtualbox来listen的，即使将上述的网卡down掉，也是能正常建立tcp连接的，这大概和virtualbox虚拟网络的实现方式有关

需要打包的虚拟机只需要保留一个网卡，nat方式的，并且网络连接上设置“自动获取ip地址”

winrm

winrm 协议报文：

 

当windows上存在了一个“未识别的网络”时（该网络被设置为了“公用”），于是winrm就不能使用，错误如下：

表现为： winrm请求虽然已经连接上了，但是不响应client发送的请求报文

理论上来讲，应该可以设置winrm listen的端口，不去listen那个“公用”的网络连接就可以了

 

参考资料：

vnc 学习

vncserve命令示例：

启动vnc：

 

查看有哪些session：

再启动一个：

查看：

删除指定session：

 

vncserve listen哪个端口？

每个session占用一个单独的端口，每个session同时只能有一个用户使用； 通过 :number 启动的session，其listen的端口号为 5900 + number

对于client来讲，使用vnc不同于其他服务，不需要指定端口号，而是指定number，如：

172.16.10.10:1

那么client就按照约定的规则，连接 172.16.10.10:5901 端口

linux 之多网卡问题

现象：

centos  6或7上配置两块（或者多块）网卡，如果默认网关配置在eth1（ip1）上，则通过另外一块网卡（如eth2（ip2））访问该主机就是访问不了的；但是，如果在eth2上做一个桥br2（ip2），该主机上面的虚拟机桥接该网卡，并且虚拟机的ip地址为ip3，则从其它主机上虽然访问不了ip2，但是可以访问ip3，就是说，访问虚拟机是正常的

调试：

  1. ping ip2 的时候，在eth2上是可以用tcpdump抓到数据包的，显示，服务器收到了数据包，但是出于某种原因，服务器没有回包
  2. 在服务器上使用ping -I eth2 ipx(这里假定其它主机的ip地址为ipx），eth2上没有数据包出现，显然，出于某种原因，服务器根本没有发包出去
  3. 两块网卡配置没有太多差异，唯一的差异就是默认网关在谁身上，默认网关很大程度上（不完全）表现在默认路由上，好吧，把默认路由删掉，给ipx单独添加一条路由，结果对上述测试没有任何影响

分析：

  1. 应该和服务器本身有关系，和其他外部的设备都没有关系
  2. 应该和内核有关系吧（晕，不好猜吧）

查资料：

  1. 发现和一个叫做 rp_filter的内核参数似乎有关系，修改如下：

    结果： 好了
    参考资料： http://blog.csdn.net/cybertan/article/details/9087829

    说明：

    1. 两个配置都需要，如果其中一个为1，则内核就参考谁
    2. 如果是br2桥接到eth2上的情况，访问br2是否正常则和eth2的该配置没关系，需要设置br2的该参数

关于rp_filter:

rp_filter : BOOLEAN
默认值为False

  • 1 – 通过反向路径回溯进行源地址验证(在RFC1812中定义)。对于单网卡主机和stub网络路由器推荐使用该选项。
  • 0 – 不通过反向路径回溯进行源地址验证。
  • 默认值为0，但某些发布在启动时自动将其打开。 (router默认会路由所有东西﹐就算该封包’显然’不属於我们的网路的。常见的例子﹐莫过於将私有 IP 泄漏到 internet 上去。假如某个网卡﹐其上设定的网络地址段為
    195.96.96.0/24﹐那么理论上不会有212.64.94.1 这样的地址段封包会到达这个网卡上。许多人都不想转发非本网段的数据包﹐因此核心设计者也打开了方便之门。在 /proc 裡面有些档案﹐透过它们您可以让核心為您做到这点。此方法被称為 “逆向路径过滤(Reverse Path Filtering)”。基本上﹐假如对此封包作出的回应﹐不是循其进入的网卡送出去﹐那它就被置之不理。)

docker mount on fly（容器动态挂卷）

理论上来讲，mount操作一定是发生在容器启动之后的（包括宿主机也如此）；但是，docker只是在create好run的时候提供了挂载卷的方法，一旦容器被创建，我们将再没有机会给容器挂载新的卷了；如果非要这么做的话，只能销毁、重新创建容器，好生繁琐。

既然理论上可以在容器启动之后挂载新的卷，docker没有提供相应的API，那么又该如何做呢？

  1. 办法一： hack一下docker，提供这方面的功能； 缺点： 随着docker版本的升级，代码维护起来比较麻烦
  2. 办法二： 从系统层面来实现，参考： https://jpetazzo.github.io/2015/01/13/docker-mount-dynamic-volumes/

办法二还是比较科学的，这里测试了一下，确实好用，脚本如下：

 

docker-enter 下载地址： https://github.com/jpetazzo/nsenter

注意：

  1. 这里用到了一个importenv的程序，可以参考容器环境变量来设置执行命令的环境变量，是个不错的办法，只是引入了一个其他的程序
  2. 这个要求容器中安装mount命令，该命令的依赖比较多，而且很少使用，所以，容器中一般都没有，需要手动安装，如果去掉那些依赖，单独安装一个mount命令会好一些
  3. 这个方法不适用于不基于块设备的文件系统，只有在/proc/mounts能正确得到块设备节点（上面谈到，并不总是能正确得到）的时候才能起作用。（比如： cephfs挂在的目录就不行）

ftp之EPRT/EPSV

参考资料：

https://tools.ietf.org/html/rfc2428

当知道了ftp有主动模式、被动模式，而且能在合适的时候选择使用合适的模式时，觉得自己NB了不少，然后在写简历的时候就写“精通ftp”。

突然，有一天，使用curl拉取ftp服务器上的文件，主动模式和被动模式都不好使了，但是使用原始的ftp client却没有问题，遂无所适从。

抓包分析发现，其实，二者差别不太大，就主动模式来讲，curl使用的是EPORT指令，而命令行ftp使用的是PORT 指令，没准儿问题就出现在这里；curl提供了一个–disable-eprt 选项，添加该选项，curl便不再使用EPORT 而是使用PORT了，问题解决；相应地，curl还有一个–disable-epsv 选项，告知curl在被动模式下，使用PSV 而不是EPSV;

E 即： extend

为了迎接ipv6的到来，ftp命令也做了一些支持ipv6的扩展，就比如说是EPORT、EPSV，但是有些ftp服务器可能不支持该特性或是禁用了该特性，这时候就只好退而求其次了

squid是一个很经典的代理，是支持ftp的，默认情况下是使用的新的ftp指令，如果遇到上述情况，可以通过修改squid配置文件来禁用扩展的指令： ftp_eprt off  或  ftp_epsv off  ( http://www.squid-cache.org/Doc/config/ftp_eprt/ )