crontab 依赖

crontab不大，但是依赖却不少

 

 

关于php的max_execution_time

缘起：

一个php-fpm的请求执行时间会比较长，总是执行不完就中止了；查看php错误日志，显示执行时长超过了60s。

为什么呢？

参考php官方文档：http://php.net/manual/en/info.configuration.php#ini.max-execution-time

max_execution_time integer

This sets the maximum time in seconds a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server. The default setting is 30. When running PHP from the command line the default setting is 0.

The maximum execution time is not affected by system calls, stream operations etc. Please see the set_time_limit() function for more details.

You can not change this setting with ini_set() when running in safe mode. The only workaround is to turn off safe mode or by changing the time limit in the php.ini.

Your web server can have other timeout configurations that may also interrupt PHP execution. Apache has a Timeout directive and IIS has a CGI timeout function. Both default to 300 seconds. See your web server documentation for specific details.

说明：

  1. 命令行执行php没有执行时长限制，尽管显式在php.ini中配置、或者ini_set(“max_execution_time”, n)、或者set_time_limit(n) 都是没用的；
  2. 尽管使用ini_set(…) 、set_time_limit(..) 后，也能通过ini_get(..)发现设置的值确实发生变化了，对于命令行也是没有作用的
  3. 命令行php -i 查看到的 max_execution_time 总是0
  4. 所以： 命令行程序对于PHP执行时长限制的担心都是多余的,cli 模式下max_execution_time被硬编码为0了
  5. max_execution_time 的默认值是30s

 

关于set_time_limit:  http://php.net/manual/en/function.set-time-limit.php

  1. set_time_limit(n) 会重置时间计数器，就是说是从该函数调用的时候计数n的
  2. php-fpm的脚本中执行set_time_limit(n)、或者ini_set(“max_execution_time”, n) 是无效的
    虽然这样更加安全，但是不符合定义： http://php.net/manual/en/info.configuration.php ；这里
    有说明max_execution_time的可修改限制为PHP_INI_ALL，就是说任何条件下都可以随时修改： http://php.net/manual/en/configuration.changes.modes.php

 

结论：

  1. 命令行程序对于PHP执行时长限制的担心都是多余的
  2. php-fpm环境下，试图在脚本中修改max_execution_time是没有用的
  3. 所以，max_execution_time 一般在php.ini 中定义

 

linux 进程按启动时间排序

办法1：

进程在/proc 下面表现为一个目录，也可以使用stat /proc/pid 来查看进程创建时间

测试发现  按照lstart排序结果比较奇怪，不知道排序规则是啥：

 

办法二： k 选项指定排序列

按照启动时间升序排列

按照启动时间降序排列

 

先按照uid升序，再按照启动时间降序

 

参考：

http://serverfault.com/questions/27887/how-to-sort-ps-output-by-process-start-time

如何获取进程启动时间

如何获取进程年龄

git 通过cron自动拉取最新代码

git 可以deploykey的方式来clone代码，但是git没有提供一个参数来指定key的路径，如何是好？

git通过deploykey的方式clone代码其实走的就是ssh，git 2.3.0后会参考一个环境变量GIT_SSH_COMMAND，完全可以通过定制该命令来指定key的路径，如下：

或许在某些情况下-i选项可能会被配置文件中的定义给覆盖掉，那么可以添加 -F /dev/null 选项禁用可能的配置文件，如下：

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指定