logrotate

手动执行logrote 测试命令

logrotate -d  debug 调试

 -f  force  强制执行， 跟想要执行的 日志轮询的 单独配置文件

配置文件 ，参数  create 和  　copytruncate  的区别：

总的说 就是 create = mv + cerate , copytruncate = cp + echo > log file 

详情如下：

1）create：

这也就是默认的方案，可以通过 create 命令配置文件的权限和属组设置；这个方案的思路是重命名原日志文件，创建新的日志文件。详细步骤如下：

1. 重命名正在输出日志文件，因为重命名只修改目录以及文件的名称，而进程操作文件使用的是 inode，所以并不影响原程序继续输出日志。

2. 创建新的日志文件，文件名和原日志文件一样，注意，此时只是文件名称一样，而 inode 编号不同，原程序输出的日志还是往原日志文件输出。

3. 最后通过某些方式通知程序，重新打开日志文件；由于重新打开日志文件会用到文件路径而非 inode 编号，所以打开的是新的日志文件。

如上也就是 logrotate 的默认操作方式，也就是 mv+create 执行完之后，通知应用重新在新文件写入即可。mv+create 成本都比较低，几乎是原子操作，如果应用支持重新打开日志文件，如 syslog, nginx, mysql 等，那么这是最好的方式。

不过，有些程序并不支持这种方式，压根没有提供重新打开日志的接口；而如果重启应用程序，必然会降低可用性，为此引入了如下方式。

2）copytruncate：

该方案是把正在输出的日志拷 (copy) 一份出来，再清空 (trucate) 原来的日志；详细步骤如下：

1. 将当前正在输出的日志文件复制为目标文件，此时程序仍然将日志输出到原来文件中，此时，原文件名也没有变。

2. 清空日志文件，原程序仍然还是输出到预案日志文件中，因为清空文件只把文件的内容删除了，而 inode 并没改变，后续日志的输出仍然写入该文件中。

如上所述，对于 copytruncate 也就是先复制一份文件，然后清空原有文件。

通常来说，清空操作比较快，但是如果日志文件太大，那么复制就会比较耗时，从而可能导致部分日志丢失。不过这种方式不需要应用程序的支持即可。

　

说下： ssh 从 客户端向服务器连接时  出现   REMOTE HOST IDENTIFICATION HAS CHANGED

前提条件：  从跳板机 用  公钥连接 会出现这个错误， 

原因： 从跳板机 用账号  用 公钥连接时， 每次ssh 连接成功后， 客户端，即 跳板机，你的账号下 有一个 known_hosts 文件，路径：  ~/.ssh/known_hosts ，存储的是每次 ssh 连接后 的 被连接机器的 指纹

格式： 目标IP:端口（如果ssh 用的22 端口，默认不加，）   空格  指纹

如果一台机器重装了（ 每次系统重装后，ssh 生成的系统指纹都不一样，即使 对 同一台机器而言），机器指纹变了，但 跳板机存储的指纹是 机器 上一个系统对应的指纹，会出现报错 REMOTE HOST IDENTIFICATION HAS CHANGED 

解决办法： 将机器公钥信息从跳板机的 known_hosts 文件里删除， 新的连接建联成功会，会将新的公钥信息重新写入。

注意区别是   跳板机记录的某台机器 指纹信息（唯一）  和  服务器本身的  指纹信息。（服务器公钥怎么在服务器上查看，？？？？）和 服务器的某个用户的公钥信息。

更改连接服务器 时，不验证指纹信息，不记录指纹信息：

改如下配置，跳板机上： 

. 修改配置文件“~/.ssh/config”，加上这两行，重启服务器。
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null