轻松的……只有一个办法，让别人请你入职

全部服务器，包括我自己个人的，都是 enforcing。少数自己写的服务，没有 remote execute 风险的都是 permissive，有风险的都写了对应的 module。容器一类的用了 kata container 这种基于 kvm 虚拟化的容器方案，所以容器一类都 permissive 了。

推荐阅读：
https://wiki.gentoo.org/wiki/SELinux
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index

建议自己多用包管理查查看。

另外如果用 mac，可以用 docker 把 linux 的 man page 都 cp 出来

```
guochao@desktop ~ % sudo dnf search man-pages-
上次元数据过期检查：2:00:09 前，执行于 2020 年 01 月 22 日 星期三 08 时 15 分 26 秒。
==================================================================================== Name 匹配：man-pages- ====================================================================================
......
man-pages-zh-CN.noarch : 中文 man pages
......
libguestfs-man-pages-uk.noarch : Ukrainian (uk) man pages for libguestfs
guochao@desktop ~ % docker run -it --rm ubuntu:18.04 bash -c 'apt update; apt search manpages'
Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
......
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [37.4 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [2496 B]
Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [4241 B]
Fetched 17.5 MB in 7s (2601 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
Sorting... Done
Full Text Search... Done

.....

manpages-zh/bionic 1.6.3.2-1 all
Chinese manual pages

tclx8.4-doc/bionic 8.4.1-2 all
Extended Tcl (TclX) - manpages

unity-scope-manpages/bionic 3.0+14.04.20140324-0ubuntu3 all
Manual pages scope for Unity

guochao@desktop ~ % docker run -it --rm archlinux/base bash -c 'pacman -Sy; pacman -Ss man-page'
:: Synchronizing package databases...
core 135.1 KiB 1145 KiB/s 00:00 [#####################################################################] 100%
extra 1644.3 KiB 2.79 MiB/s 00:01 [#####################################################################] 100%
community 4.8 MiB 3.90 MiB/s 00:01 [#####################################################################] 100%
core/man-pages 5.04-2
Linux man pages
extra/opengl-man-pages 20190725-1
OpenGL Man Pages - OpenGL 4.x
community/man-pages-cs 0.18.20090209-6
Czech man pages
community/man-pages-de 2.16-1
German Linux man pages
community/man-pages-zh_cn 1.6.3.3-1
Simplified Chinese Linux man pages
community/man-pages-zh_tw 1.6.3.3-1
Traditional Chinese Linux man pages
community/python-argparse-manpage 1.1-3
Automatically build man-pages for your Python project

```

这种进程不退出的问题可以尝试下 linux 的 systemd 或者直接 cgroup，或者 docker。docker 下面就是得把沙箱关掉，麻烦一些。

我们开发环境和生产都是 Fedora/CentOS，开着 SELinux。用的是 puppeteer。遇到的问题是这样，有的时候 chromium 本身父进程会崩溃，或者 blink 的渲染进程 bug 阻塞了通信导致 timeout，最后无法正确关闭。解决办法就是利用 cgroup 记录 pid，顺便限制一下资源占用，退出时一次性把这个 cgroup 下所有 pid 杀死。

chrome 的 devtools 协议的话，还可以尝试一下 node 的 puppeteer 和 golang 的 chromedp，都是直接启动 chrome/chromium 不需要 chromedriver 的

我自己闲的时候写的东西也是需要些并发啊什么的。一开始用 nodejs，用不熟，后来换 python，最近一两年又因为试着学 go 换成了 go。所以建议的话：

能换 go 换 go，天生就是自己调度的协程，只要代码没问题效率就不会低。就跟具体用什么库没关系了。

如果要用 python 的 tornado/asyncio 的话，建议用 aio-pika 这种库，或者用 aioredis 撸一个，新的 redis 自带 pub sub，不用 pubsub 也可以用 list 或者 sorted set 来做队列。另外就是楼上说的，注意一下别的库的实现，搞不好会给你阻塞一段，遇到这种了就用 ThreadExecutor，我们公司这边 python 的项目就是 patch 了很多同步的库然后自己用。

node 理论上应该也还好，但是一个是我不熟悉 node，当时不知道为啥用 node 的 redis 会阻塞住，另一个是印象里 node 不开进程线程的话是单线程的。我就不多提这个了

chroot 只是切根，跟 virtualenv 什么的不大一样，docker 也不大一样。

先说 use case。我习惯的场景：
- chroot 只在从 Linux 里面装 Linux 时使用。需要先展开文件系统、挂载 sys procfs devtmpfs efivars 等等等文件系统，很麻烦的。举个例子，我装 Arch 用的 arch-chroot 就是一个 chroot 的 wrapper
- docker 只是打包管理应用。如果遇到一连串的共享库不一致我可能也会用 docker，或者用类似于 conda 的处理方法。
- conda、virtualenv、我自己写的一些简单的 helper 主要是处理个别程序需要在不同的二进制 /共享库环境下的需求，一般是脚本一类程序的解释器版本的问题或者脚本的库的目录，或者是共享库需要 X Server 以及不一样的版本（ preload ）

virtualenv 和 conda 之类的工具主要是修改环境变量来修改 shell 和各种工具执行、加载各种程序的行为，比如说 PATH PYTHONPATH PERL5LIB LD_PRELOAD 这些，通过这种方式在一个终端里面执行另一套程序。自己就可以写一些工具来做类似的事情

chroot 实际上是调用了一个 chroot 的函数（ http://man7.org/linux/man-pages/man2/chroot.2.html ），让子进程可以把这个目录认作根目录。并没有隔离太多资源，你实际上还是在同一个命名空间里面用了同样的资源。而且 chroot 需要你提前准备好一套类似于容器镜像的文件系统，很多情况下你还需要把 host 的目录挂载进来才能让程序正常运行。很麻烦的。
此外 chroot 以后如果不切换为普通用户，是可以逃逸出根目录的。

docker 则是利用了 namespace 和 cgroup 来控制和隔离一个进程树，而且用了大量技巧来阻断进程逃逸的过程，而且这几年也出了非常多的基于 kvm 的 runc，相当于轻量级虚拟机，微软打算做的 wsl2 应该是差不多的东西，比如说 kata container，逃逸的难度非常大。而且可以利用现有的 image。主要是为了编排服务出现的。