本来以为很快安装完了，没想到安装过程中缺少不少文件，就决定再记录一下吧。 看系统软件库里版本太低，我就想直接源码编译安装。官网下载了2.4.3的版本。 编译命令：make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1，这个是开启所有模式的编译方式，可看INSTALL文件配置 需要安装gcc:yum install gcc.x86_64 需要pcre:yum install pcre-devel.x86_64 需要openssl: yum install openssl.x86_64 openssl-devel.x86_64 需要安装lua，需要5.3版本以上，我从lua官网下载了5.4.3版本，可以直接make后，指定lua目录。make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1 LUA_INC=/opt/source/lua-5.4.3/src/ LUA_LIB=/opt/source/lua-5.4.3/src/ 需要systemd-dev:yum install systemd-devel.x86_64 然后我现在记录才发现，就是参数指定的都需要额外安装的软件。 haproxy 配置文件 mkdir /etc/haproxy cp examples/option-http_proxy.cfg /etc/haproxy/haproxy.cfg 配置systemd cd admin/systemd/ make 会生成一个haproxy.service，我看就执行了替换bin目录 cp haproxy.service /usr/lib/systemd/system/ systemctl enable haproxy 直接start还是有问题，日志查看错误，需要改一下默认的配置文件和设置ulimit。 具体的详细配置还没看,只先瞟了一眼logging的配置。

安装没啥坑，提示还挺好，照着官方文档安装，基本都是回车：http://9p.io/wiki/plan9/installation_instructions/ 踩了三个坑， 一个是我选文件系统的时候选的fossil+venti ，硬盘选了2G，然后自动分区的时候可能把fossil分区的太少，复制文件的步骤太慢，而且各种报错，太慢了我感觉不堆，我又重启复制，报不同的错，最后才提示磁盘不足。我又重新开了个10g的硬盘，然后就可以了。 开始我还以为选择的镜像路线不对，然后发现可以ctrol+d退回到主菜单。 之后复制不到一分钟就复制完了，这个才是现代机器的速度嘛。然后重启后，输入用户名那里，提示的是none，我还以为进去创建文件，没想到的是需要输入默认用户名glenda，这个在安装文档里有，我后来报错才去看的文档。 放一张启动后的界面吧，感觉ui挺好看，就是还不成熟，vb中bug还挺多的。 我还看了点官方介绍，感觉备份那个思想现在Windows，mac应该都有，还有远程文件系统现在也都有，应该没啥新内容。待发掘

plan9可能有点古老了，看官网是80年代的产物，感觉那时候还没有操作系统垄断，dos可能也就刚出来，Windows还不知道在哪。今天想起来了，我又找了篇文章看了看plan9的介绍，反而激起了我对plan9的兴趣，感觉有些理念可以借鉴。被垄断后的思维就会狭隘，偏见，开开视野也是好的。 感觉好多古老的玩意还挺有意思的，比如老早之前知道，磁芯大战(core war or core wars)，细胞自动机（cellular automata）,《一种新科学》（A New Kind of Science）Stephen Wolfram。（这本书大体看了一下，有些思想我之前倒是想过，却没有这么深入细致的去研究） 记几个关键字，后边研究一下 装一下panl9操作系统，配置看一下那些特性，代码应该不会看。 Sam 和 Acme编辑器大体看看。 顺带知道一个操作系统Oberon，发现搜着看着东西越来越多了。 最近又看了篇文章，加深了对erlang的理解，之前还学过erlang语法，有时间再看看vm。 立了flag，不知道能不能看，发现要弄的东西不懂就难搞，不知道能不能坚持下来。下午有时间把plan9装一下。

准备玩点高级一点的东西了，xelatex看着不错，搜了一番，感觉texlive比较不错。也下载了Texmacs，那个只支持原生的latex，xelatex的导入导出不支持。现在已经懒得折腾东西，但是想想还是折腾折腾吧。直接apt安装的版本是2017的，感觉有点老，所以还是装个新的玩吧。 安装基本靠官网文档 首先下载一个安装工具，解压，执行perl install-tl 。 这里要看一下安装目录是否有权限，texlive的安装不需要root权限，但是默认安装目录是/usr/local/texlive/2020，最后一级目录是区分不同版本的，所以只要创建texlive目录，然后保证有权限就行了。 然后i开始安装，看着好像要下载四千多个文件，我使用的默认的镜像，速度还挺快的。主要看下载安装工具的时候速度就挺快。 还有gui版本的安装工具，包括安装完成后gui工具的使用，这个需要perl的tk库，sudo apt-get install perl-tk进行安装。比如：tlmgr -gui 更新系统使用命令：tlmgr update -all

Callgrind是valgrind的一个工具，能够分析程序运行效率，帮助找到程序瓶颈。 命令tool知道使用的valgrind的工具， valgrind --tool=callgrind ./a.out 运行完之后会生成一个callgrind.out.PID文件，然后执行下面命令进行分析 callgrind_annotate callgrind.out.PID 这个命令能够展示每个调用函数对应的执行指令的次数，展示已经排序，可以优先优化最顶部的函数。 cachegrind也是valgrind的一个工具，主要分析内存使用情况的，比如cpu cache的使用等。 简单使用命令： valgrind --tool=cachegrind ./a.out ==12810== ==12810== I refs: 13,413,053,205 ==12810== I1 misses: 3,851 ==12810== LLi misses: 3,552 ==12810== I1 miss rate: 0.00% ==12810== LLi miss rate: 0.00% ==12810== ==12810== D refs: 4,991,204,111 (3,140,940,594 rd + 1,850,263,517 wr) ==12810== D1 misses: 49,675,548 ( 38,504,518 rd + 11,171,030 wr) ==12810== LLd misses: 29,710,307 ( 19,488,129 rd + 10,222,178 wr) ==12810== D1 miss rate: 1.0% ( 1.2% + 0.6% ) ==12810== LLd miss rate: 0.6% ( 0.6% + 0.6% ) ==12810== ==12810== LL refs: 49,679,399 ( 38,508,369 rd + 11,171,030 wr) ==12810== LL misses: 29,713,859 ( 19,491,681 rd + 10,222,178 wr) ==12810== LL miss rate: 0.2% ( 0.1% + 0.6% ) 看着好像程序我的程序允许的比预期的缓存命中高很多，看官方文档说的。On a modern machine, an L1 miss will typically cost around 10 cycles, an LL miss can cost as much as 200 cycles, and a mispredicted branch costs in the region of 10 to 30 cycles. Detailed cache and branch profiling can be very useful for understanding how your program interacts with the machine and thus how to make it faster.现代机器，L1缓存丢失通常花费10个cpu周期，LL丢失花费200个周期，分支预测错误花费10-30个周期，所以这部分性能分析很重要啊。 LL指的是最后一级的cpu缓存，许多cpu架构可能有多级缓存，L1和LL具有代表性，所以只分析了这两种。 程序还是会生成一个cachegrind.out.PID文件，同样可以具体分析每个函数的内存使用情况 cg_annotate cachegrind.out.12810 这俩工具在官方手册上，每个一章进行介绍，具体也没研究，先初步了解一下

先说一下pyenv的安装方式，只有两步，第一步是将github项目clone到目录，第二步是添加环境变量。所以pyenv完全可以离线安装，比如操作系统版本一致的时候，直接把装好的pyenv环境和virtualenv环境复制到目标系统就可以了。然后添加一下环境变量。 我之前安装过pyenv了，更新pyenv进入pyenv目录后，执行git pull。 然后我复制了一份新的代码，改变环境变量，切换到新pyenv目录。然后卸载之前直接安装的python版本。pyenv uninstall 3.7.3 进入.pyenv_bak，mkdir cache.将源码包放到cache目录下。 进入.pyenv_bak/plugins/python-build/share/python-build目录，编辑3.7.3文件 #require_gcc prefer_openssl11 export PYTHON_BUILD_CONFIGURE_WITH_OPENSSL=1 install_package "openssl-1.1.0j" "https://www.openssl.org/source/old/1.1.0/openssl-1.1.0j.tar.gz#31bec6c203ce1a8e93d5994f4ed304c63ccf07676118b6634edded12ad1b3246" mac_openssl --if has_broken_mac_openssl install_package "readline-8.0" "https://ftpmirror.gnu.org/readline/readline-8.0.tar.gz#e339f51971478d369f8a053a330a190781acb9864cf4c541060f12078948e461" mac_readline --if has_broken_mac_readline if has_tar_xz_support; then install_package "Python-3.7.3" "https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz#da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip else install_package "Python-3.7.3" "https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz#d62e3015f2f89c970ac52343976b406694931742fbde2fed8d1ce8ebb4e1f8ff" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip fi 改成 install_package "Python-3.7.3" "/root/.pyenv_bak/cache/Python-3.7.3.tar.xz" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip 安装 pyenv install 3.7.3 安装完成后执行pyenv virtualenvwrapper，我发现需要重新安装这个插件，不知道为什么。我之前是安装了的，可能版本问题。 然后基本就可以了。virtualenv也是可以直接复制的，所以基本可以复制分发了。

rootkit hunter能检查一下系统是否被安装后门，听说很厉害。 去官网下载一个tar包，解压 安装 ./installer.sh --layout custom /opt/temp/rkhunter --install 这个是指定安装目录，日志都会打到/var/log/rkhunter.log 更新rootkit hunter的数据库 /opt/temp/rkhunter/bin/rkhunter --update 进行检查 /opt/temp/rkhunter/bin/rkhunter --checkall 然后查看结果 cat /var/log/rkhunter.log|grep "Warning\|Vulnerable" cat /var/log/rkhunter.log|grep -A 30 "System checks summary" 这个关键字可能不准确，具体看看总结，再细看检查的过程。

jenkins有好的方面，只有一个war包，目录基本兼容版本，迁移方便，可以在不同机器上编译。 今天打的包突然说代码没上去，然后查发现真没上去，啥都没改就出问题了。看jenkins打包日志没报错，checkout的分支也是对的。然后查workspace，svn log命令还执行不了，说版本不一致的啥问题，之前从一台机器迁移到另一台机器，两台机器的版本不一样就折腾了好久。但是也没再动，然后执行svn upgrade可以看log，一看没有新代码版本。卧槽急了一身汗，办公室也热。 然后跟同事一起分析，然后又看了一遍jenkins打包日志，在checkout代码完了之后，发现有个警告。。

WARNING: clock of the subversion server appears to be out of sync. This can result in inconsistent check out behavior.
同步了一下服务器时间就好了。网上说 在jenkins job的 svn地址后边加个 @HEAD 也行。
之后的项目等加上@head

supervisor的版本3.0a8的版本不支持stopasgroup的参数，感觉很痛苦。准备升级，debian的版本有点老，不支持apt-get升级。
然后准备用pip install安装新版本。



	

Stop service:

service supervisor stop


	
Backup current configuration:
mkdir ~/supervisor
cp -r /etc/supervisor ~/etc-supervisor
cp /etc/default/supervisor ~/supervisor/etc-default-supervisor
cp /etc/init.d/supervisor ~/supervisor/etc-init.d-supervisor


	
Remove current installation:
apt-get purge supervisor
rm -fr /etc/supervisor


	
Install new supervisor:
pip install supervisor


	
Restore configs:
cp ~/supervisor/etc-default-supervisor /etc/default/supervisor
cp ~/supervisor/etc-init.d-supervisor /etc/init.d/supervisor
cp -r ~/etc-supervisor /etc/supervisor
ln -s /etc/supervisor/supervisor.conf /etc/supervisor.conf #这一步新版本没必要


	
Start new supervisor:
service supervisor start


	
Verify:
supervisorctl


	
Set to run at startup:
update-rc.d supervisor defaults



这样做完有个问题是pip install的目录是/usr/local/bin/目录，需要修改/etc/init.d/supervisor的文件里的路径。

清除vim搜索历史 :call histdel('/') 寄存器文档 :help registers ,少输入了一个然后文档没查到。用google直接搜文档找到了，，