bind mount 子目录

no silver bullet

php-7.4 依赖[libapache2-mod-php7.4, php7.4-fpm, php7.4-cgi]之一，如果你在装 php7.4 的时候没同时指定这三个包之一，并且这三个包之一也没安装过，那 apt 会挑选一个“最合适的”来安装，这个最合适，默认是 libapache2-mod-php7.4 。如果你同时指定 php7.4-fpm ，条件满足了，自然不会再给你安装 libapache2-mod-php7.4 。

给领导准备好热水和布洛芬吧

代味（代码的滋味）

看了一下，我当年为了搞这事收藏的几篇文章（包括 OpenWRT 和 EdgeRouter 上的）都失效了……

dnsmasq-full 包根据目标域名给解析出来的 ip 打 ipset ，然后防火墙规则里对指定的 ipset 做 mangle 配合 ip rule 走路由规则

前一半自己搜搜，目标域名还有 gfwlist2dnsmasq 这个工具可以用来生成。后一半大体可以参照这篇 https://oogami.wordpress.com/2015/05/31/linux-%E7%AD%96%E7%95%A5%E8%B7%AF%E7%94%B1%E4%B8%8E%E5%A4%9A-vpn-%E5%B9%B6%E5%AD%98%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/

不过照抄是不行的。

运维岗的面试不应该问这么宽泛的问题。哪怕是招运维负责人。

PSK （公用单个密码）的问题是，如果无心（或有心）泄露给无关人员，或者被 WiFi 助手泄露，是没办法追查责任的。

那就说明你不需要。那你就不用改呗。

不是很冷的知识：王院士是工程管理学部的

这点数据量谈个屁的大数据。但是对这种运营类场景来说，大不大数据的只是表象，关键是大数据这个词所对应的需求，是从另一个维度（ analytical ）去理解业务发展，跟原来的维度（ transactional ）很不一样，思维模式、需求侧重、技术指标都不一样。所以总的来说还是个值得利用的好机会。至少可以试试看自己是否有这方面的天赋。实在做不出感觉来，以后重回 transactional 的业务开发也不是不可以。

这是在纵容事发公司后续依然不重视运维

再比如，用 logrotate ，我可以配置 pre 和 post 脚本，在 rotate 动作的前后做一些处理。

而 rotate 功能做在 application 内部了，怎么办呢？让写 application 的业务开发团队加这个功能，然后业务开发再去推写 log 库的人加这个功能？就算实现了，谁能保证专注于写业务的开发团队顺手做的能比人家 logrotate 一心一意做了这么多年积累下来的经验更可靠？那我当然是希望业务开发团队不要操心这些事情。

另外，不是说日志库完全不需要考虑 rotation 。只要留个操作，可以 reopen 当前的日志文件就行了。外部 rotation 工具在移动日志文件后往进程传一个 rotation 指示（比如 kill -HUP ），进程收到后 reopen 日志文件，就写到新的文件里去了。而不需要在日志库里对日志文件的更替做定时管理。日志库里要再加上这个功能，那又要牵扯到定时任务管理，更加复杂了。

@yuancoder 那有什么必须的理由把 rotation 做成 application 的一部分而不是外部功能呢？

作为一个运维人员，我想到用外部功能来做的主要理由是，logging 虽然不属于业务功能，但毕竟还是应用系统的一部分，属于业务发出的动作，而 rotation 则完全和业务无关，是“带外”操作，其逻辑本身就是外部化的。rotation 跟业务逻辑没有什么必然关系，生产环境所要维护的 rotation 操作，外部化之后，可以用专门做 rotation 的组件来配置足够复杂和灵活的处理规则，这些没必要让做开发的角色来操心。这种解耦有利于业务程序员和基建运维发挥各自的长处，各司其职，而不是业务程序员操心基建开发，在“进程内”造轮子，运维又要学习一堆繁杂但又不见得比现有成熟基建更强大的专用配置来吐槽。

另，以上不针对功能性的轮子。只针对日志切分、旋转这种运维性质的杂活。