curl ftp 主动模式与被动模式

curl命令访问ftp默认走被动模式，主动模式可能会不好使，比如说：

  1. curl在防火墙后面，而防火墙又不允许主动进入的连接
  2. curl所在机器有多个IP，控制链路使用的IP和数据链路期望使用不同的IP
    1. 可以通过 -P address 来指定主动模式时数据链路期望使用的IP，如果简单使用数据链路的IP，则可以直接 -P –

svn to gitlab

手动在gitlab上创建git仓库： http://gitlab.phpor.net/phpor/svn2gitlab.git

 

 

给网站开启https

https://phpor.net/blog/

开启方法： https://certbot.eff.org/

发现的几个问题：

  1. 页面中有一些google的资源，国内用户会访问不到，然后页面加载就会很慢
  2. 页面中有一些图片写的是http的绝对地址，使得https访问时，页面中加载了http的资源，显得很不漂亮
  3. 让自己的的blog支持http2
  4. https的时候登录不能成功

这里的证书是3个月的有效期，马上要到期了，根据官方提供的脚本，自动更新证书的时候需要（虽然是自动的）重新安装python（而且是编译安装），结果失败了，解决办法： 官方给了一种docker的申请方式：

https://certbot.eff.org/docs/install.html#certbot-auto

如下：

由于国内下载docker镜像很慢，可以直接在国外的机器上完成上述操作，然后，把申请好的证书拿回来配置（这样也比去某些网站申请证书来的方便的多），注意，需要把申请证书的域名解析到这个docker的机器的IP上，验证域名要用。

为了方便下次使用，还是把这个docker容器下载到国内，放在自己博客的机器上，下次就不需要修改域名解析了

写个cron自动续签证书:

提前两天自动续签证书

 

目前certbot还不支持 通配符 证书的申请 （https://certbot.eff.org/faq/#will-let-s-encrypt-issue-wildcard-certificates）

根据证书颁发的方式的不同，证书的级别也有不同，从低到高依次为： DV、OV、EV：

DV （ Domain Validation）：只验证域名（这个很简单）

OV （Organization Validation）： 验证域名和组织

EV（Extended Validation）： 验证流程更严格

目前certbot还没有计划推出EV型证书（https://certbot.eff.org/faq/#will-certbot-issue-extended-validation-ev-certificates）

 

关于申请证书频繁程度是限制： https://letsencrypt.org/docs/rate-limits/

nscd nslcd

缘起：

虚拟机配置了ldap认证，由于一次断网，ldap服务器进程还在，但是无法正常服务，查看原因，发现ldap服务器进程由于大量连接导致文件描述符占满。

虚拟机上启动了nslcd，该进程会和ldap服务器保持长连接，断网的时候，ldap服务器并不知道连接已经断开（应该是服务器端没有开启探活机制，而client端开启了探活机制），网络恢复后，client重新连接，导致连接数翻倍

解决办法：

ldap认证可以不走nslcd的，参考资料：

http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/pamnss.html

 

confd 笔记

confd 配置文件：

 

有时候，我们不想在confd启动命令中写很长的参数，那么可以通过 -config-file 来指定配置文件，如果你喜欢将配置文件的位置定义到 /etc/confd/confd.toml ,那么一个参数也不需要，因为，这就是默认搜索的配置文件

一个confd.toml 的示例：

 

一个conf.d/upstream.toml

其中：

  1. prefix 就是要（递归）watch的结点，watch的返回值是变化结点的原值和新值
  2. keys是当发生更新时从哪些结点获取数据（来渲染模板），这里的结点必然是prefix下的，不能是prefix外部的，所以，如果期望变更不会被立即触发，而是一组变更完成后才被触发，这里是做不到的；比如： 期望同一时间更新多个upstream，而只重启一次nginx，这里做不到；除非自己实现，自己实现也要考虑很多东西，如：模板渲染如何实现？
  3. watch总是递归的，这个代码中写死的，没得配
  4. 这里的prefix最好从confd的根开始，不要指望和confd.toml中的prefix拼接使用； 如果 confd.tomal 中的prefix 是 /sa  而upstream.toml 中的prefix是 /nginx， 则-onetime执行时可以看到预期的效果（生成了期望的目标配置文件），但是watch的时候却不能达到预期的效果；非常怀疑这是个bug，因为，confd启动的时候可以渲染出来正确的目标配置文件（参考了confd.toml 中的prefix），后续watch的时候却没有参考confd.toml 中的prefix，所以自然watch不到了：tcpdump部分截图如下：
    初始渲染的请求：

    watch的请求：

模板文件示例：

注意：

  1. 模板中的指令，默认会导致生成的文件中出现多余的空行的，解决办法就是使用 -}}
  2. 模板中可以构造变量（如：通过printf拼接字符串）
  3. 参考： https://github.com/kelseyhightower/confd/blob/master/docs/templates.md

 

watch的实现：

  1. 查询请求中，wait参数为true就是watch，wait可以指定waitIndex，当然也可以不指定，不指定的话逻辑比较简单，就是有变化就响应；如果指定的waitIndex已经发生过，则直接返回曾经的变化结果（这是历史上指定版本的值，可能不是现在的）；如果waitIndex是下下次的版本号，则下次变化将不会被感知到
  2. wait可以递归也可以不递归，通过参数recursive指定

 

关于linux下的capability

Linux的capability深入分析

从编程的角度深入分析了linux下capability的概念，相关工具 libcap

学以致用：

Docker容器往往被剥夺了很多能力，如此在容器启动之后想做一些能力之外的事情该咋办？其实，容器毕竟是容器，和虚拟机是有区别的，我们可以可以限制容器内进程的能力，我们也可以把一个具有超能力的进程放到容器里面执行，这样就可以做一些原本容器没有能力做到的事情，比如： docker exec –privileged … 。

如下图：

结论： 我们不担心容器是在非特权模式下启动的，只要我们想要权限，就可以通过某种方式（如： –privileged）将一个特权进程放到容器里面做特权的事情

etcd 的访问控制

https://coreos.com/etcd/docs/latest/auth_api.html

auth enable 之前必须添加root用户，添加时设置密码：

开启认证：

添加一个非特权账号：（注意，这时候就需要有权限的用户来操作了）

查看有哪些账号：

添加角色：

给角色添加能力：

通过 –help 查看用法：

注意，这里只添加了 /test1 的读写权限，不包含其子目录（文件），如果需要包含，请这么写：

查看有哪些角色了：

查看指定角色的权限：

将用户添加到角色：

查看用户拥有哪些角色：

列出etcd中的所有key：（-p 选项在目录的后面添加 /）

关于用户的更多操作：

 

 

 

 

rpm打包

基础知识

  1. 打包根目录，默认user home目录下的rpmbuild，如下：

     
  2. 打包共需要几个子目录，如下：

    其中：
    SPECS：spec文件目录，其实你完全可以spec文件放在任意你喜欢放置的地方
    SOURCES: 源码目录，spec中Source指定的文件如果是相对路径就来这里找，当然，Source可以是一个url地址； 该目录位置由 _sourcedir 定义，如：

    该目录可以没有，如，通过命令行选项的–define来定义一个指定的路径，如下：(将源码目录定位到当前目录)

    BUILD：%setup指令默认会将源码解压缩到该目录，并在该目录下进行编译
    BUILDROOT：%make_install 宏会将需要安装的文件安装到该目录下，用于生成rpm包
    RPMS：编译好的二进制rpm文件以及debuginfo rpm文件会放到该目录下，如：

    SRPMS：一般来讲，二进制RPM是指定平台下的，在不同的平台下需要重新编译，而SRPMS目录是用于放置带有源码的rpm文件，该rpm文件在安装时会进行及时编译的，如：在对openresty进行rpm打包时有如下srpm文件生成：

    源码的rpm包包含需要的源码和一个spec文件（二进制的rpm包不包含spec文件）
  3. 基于源码编译的rpm包一般(rpmbuild -ba )会产生三个文件，openresty打包产物如下：
  4. 其实你完全可以在spec文件中没有编译操作而只是把预先准备好的二进制文件install到BUILDROOT下，然后生成二进制的rpm文件，但是似乎没有同时产生三个rpm文件显得专业

SPEC文件说明

spec文件中有一大堆的宏和类似宏的东西，搞懂这些对rpm打包极为重要。

%setup

该宏的作用是，将源码安装到BUILD目录下，无参情况下的%setup等价于：

-n选项：

如果source解压后的目录名不是spec中定义的 %{name}-%{version}, 那么目录切换就会出错，这时候可以使用-n参数，如： %setup -n phpor ,则上面逻辑中的 %{name}-%{version}将会是-n指定的参数phpor

-c选项：

如果源码目录不是在一个指定的目录下，如： 对于软件phpor-1.0，目录结构如下：

如果： tar -zcf phpor-1.0.tar.gz phpor-1.0  则比较正常

如果： cd phpor-1.0 && tar -zcf phpor-1.0 * 则解压出来将没有phpor-1.0这个目录，而是x1 x2 x3 三个目录（或文件），这时候就需要在打rpm包的时候预先创建phpor-1.0这个目录，然后解压到该目录，这就是使用-c的作用了

更多参考： http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-MULTI-SOURCE

 

%prep

其实该宏很简单：

%install

%makeinstall

%make_install

%files

最好写的细一些，不要直接写 / (根目录）

  1. 配置文件使用%config指定
  2. 如果需要往 /etc/init.d 下安装启动脚本，则更不能直接写 / ，因为这意味着还要安装目录 /etc/init.d ，而该目录已被chkconfig包所使用，会出现冲突，所以可以添加对chkconfig包的依赖（当然不明确声明也没关系，只要/etc/init.d 目录存在即可），然后只安装需要安装的/etc/init.d/下面的脚本

%config

配置文件可以通过该指令指定，配置文件比较特殊，有时候期望卸载软件的时候配置还能保留；rpm是这么处理配置文件的：

  1. 如果配置文件没有修改过，卸载软件时删除
  2. 如果配置文件修改过，卸载软件时备份到其他文件，如：

     

rpmbuild 选项说明

-bp：只解压缩文件，不编译

-bc：编译但不安装

-bi： 编译、安装（到$RPM_BUILD_ROOT目录下），不删除 $RPM_BUILD_ROOT目录，不生成rpm文件，方便查看安装的位置是否正确

-ba：即生成源码rpm包，也生成二进制rpm包
其实源rpm包比较好创建，就是把指定的source和spec两个文件打成一个rpm压缩包；如果是自己已经编译过的目录（不让rpm来编译，就不会有debuginfo rpm包）

-bb： 只生成二进制rpm包

-bs：只生成源码rpm包

-t*：直接build指定的tar包，该tar包中包含了spec文件

rpmbuild debug

rpmbuild总是根据spec文件生成一个shell脚本，该脚本是%_tmppath 下的一个临时文件，具体查看 %_tmppath 的方式：

通过查看生成的shell脚本就能比较清楚地知道rpm是如何工作的，宏扩展后具体是什么

另： spec文件中是可以直接写shell脚本的，如：

 

注释

#标识注释， 注释中的%也需要用%%代替，否则也会执行宏扩展

 

 

关于PHP打rpm包：

  1. 由于扩展的安装没有参考prefix的定义，而是直接安装到系统里面的，所以执行%makeinstall 时，并没有将扩展安装到buildroot下，所以，打包的时候就打不进去，这个需要看一下如何解决

调试技巧

  • rpm打包比较浪费时间的事情是： 源码编译耗时比较长，但是spec文件容易写错，编译出问题的情况比较好解决，因为通常会把编译没有问题的命令贴到spec文件中，问题是安装部分可能会不是太满意，需要多次调试，而rpm打包总是经历编译的步骤，失败后编译使用的临时文件和目录都会删除掉，就是说，每次调试都要经历漫长的编译，然后发现安装部分还是有点儿小问题；解决办法：

办法1： 写spec文件时不删除已编译的文件，下次把%setup %config %build 部分都去掉，直接install，不过这时候需要在install的时候显式的cd到指定的目录

办法2： 直接提供编译好的文件作为源文件，然后spec文件中不写编译语句

办法3： make 时添加选项： %{?_smp_mflags}   即：如果是多处理器的话则并行编译

  • 如何了解rpm打包每个步骤都做了什么？
    rpm的好些阶段都是可以直接写shell命令的，我们不妨添加一些暂停语句使之暂停来查看其生成的中间脚本文件，如：添加 read -p “press enter to continue…” ，示例如下：

     

 

 

rpmbuild中间脚本文件：

实例：

从该脚本来看，里面并没有出现解压缩源码包（%setup）部分的逻辑，即：其中没有包含%prep %setup 部分逻辑，而是从%build部分开始的,%build 逻辑：

其实，%prep (包含%setup逻辑）是一个单独的临时脚本文件，如下：

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.L3sv7t

%build 部分是一个单独的脚本，一般包含./configure && make，如下：

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.oaK7vF

%install是单独一个中间shell脚本，如下：

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.f9kumb

其中包含生成debuginfo，如果不想生成debuginfo，则可以在 ~/.rpmmacros 中添加：

 

 

参考： 制作PHP rpm包