虽然网易云音乐官方提供了linux安装包, 无法在我目前的系统 Debian 9 上使用, 运行时报错 glib 缺少xxx之类的信息:
无奈还是用 wine 安装.
这篇文章简单记录使用 wine 安装网易云音乐的过程. wine的相关知识以及如何安装可以参考我以前的文章.
下载exe文件.
启动安装程序:
WINEARCH=win32 WINEPREFIX=/home/kelu/Wine/WeChat wine uninstaller
普通的点击install安装即可.
解决黑屏问题:
winetricks ddr=gdi
做一些基本的配置:
# Ubuntu/Debian
apt-get install xl2tpd ppp
# Centos
yum -y install xl2tpd ppp
以下<> 内部的是需要自己修改的内容，按需修改。
# /etc/xl2tpd/xl2tpd.conf 文件
[lac <id>]
name = <name>
lns = <l2tp_server_ip>
pppoptfile = /etc/ppp/peers/<id>.xl2tpd
ppp debug = no
<id> <name> <l2tp_server_ip> 大家按需求修改就好。
# /etc/ppp/peers/<id>.xl2tpd 文件
remotename <id>
user <l2tp_user_name>
password <l2tp_user_password>
unit 0
nodeflate
nobsdcomp
noauth
persist
nopcomp
noaccomp
maxfail 5
debug
systemctl start xl2tpd
查看进程状况。
systemctl status xl2tpd.service
显示正在运行。
启动成功后，表示守护进程已启动，等待新的连接操作。
连接 L2TP 服务器的命令如下:
sh -c 'echo "c <id>" > /var/run/xl2tpd/l2tp-control'
断开连接的命令为：
sh -c 'echo "d <id>" > /var/run/xl2tpd/l2tp-control'
参考ppp的配置文件,例如我的:
sh -c 'echo "c lao" > /var/run/xl2tpd/l2tp-control'
使用 ifconfig 查看网络设备，如果出现 ppp0 这个网卡项，表示连接成功了。
查看日志，可以清楚地看到连接握手状况。
journalctl -u xl2tpd -f
将要访问的ip声明为走 ppp0 网卡，使用下面的命令添加路由，我假定我们要代理的ip为 10.187.0.0/24：
route add -net 10.187.0.0/24 gw 192.168.100.254 ppp0 # 添加路由
route -n # 显示路由表
# route del -net 10.187.0.0/24 gw 192.168.100.254 ppp0 # 删除路由
添加后可以 traceroute 查看流量是否正确到达我们的对端：
最近使用 Debian 进行办公，微信在国内是必不可少的办公工具。在linux上有很两种实现方式，
两种方式对个人来说都差不多，基于web微信的可以搞更多的花样，但很可惜的是，我的账号不允许登陆 web 微信，我也不知道为什么。所以直接pass，只能走wine 微信这一条路。
这篇文章记录安装 wine 和 wine 微信的要点。
Wine （“Wine Is Not an Emulator” 的首字母缩写）是一个能够在多种 POSIX-compliant 操作系统（诸如Linux，Mac，FreeBSD和Solaris等）上运行 Windows 应用的兼容层。
Wine 不是像虚拟机或者模拟器一样模仿内部的 Windows 逻辑，而是将 Windows API 调用翻译成为动态的 POSIX 调用，免除了性能和其他一些行为的内存占用，让你能够干净地集合 Windows 应用到你的桌面。
查看内核架构：
sudo dpkg --print-architecture
如果运行的是 64 位系统，需要开启 32 位架构支持
sudo dpkg --add-architecture i386
wget -qO - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -
/etc/apt/sources.list中增加一行deb https://dl.winehq.org/wine-builds/debian/ buster main
sudo apt update
winehq-stablesudo apt install --install-recommends winehq-stable
查看wine版本号：
wine --version
- 建议使用桌面用户进行安装，root用户未来要复制一些文件会比较麻烦。我暂时切到我的桌面用户kelu。
su kelu
- 由于我一般登陆两个微信，所以我希望能同时跑两个wine来解决这个问题。所以我在运行wine前都会选择各自的独立配置。
mkdir ~/Wine
WINEARCH=win32 WINEPREFIX=~/Wine/WeChat winecfg
WINEARCH=win32 WINEPREFIX=~/Wine/WeChat2 winecfg
其中 WINEARCH=win32 的作用是告诉Wine创建一个32位的wineprefix。
wineprefix 是生成配置文件的目录。
有一个库 riched20 经常使用，提前添加一下，点击 Add：
打开软件安装界面：
WINEPREFIX=~/Wine/WeChat wine uninstaller
选择 Install 安装微信：
安装完成。再次打开微信可以这样打开：
cd ~/Wine/WeChat/drive_c/Program Files/Tencent/WeChat
WINEPREFIX=~/Wine/WeChat wine WeChat.exe
上面可以看到了，中文字符都是方框。下面来解决中文字符问题。
无脑把win7的字体文件夹 C:\WINDOWS\Fonts\ 打包复制一份到 Linux系统中。因为我起了两个配置文件，就是分别拷贝到下面的文件夹：
gedit ~/Wine/WeChat/system.reg # 一定要使用 gedit 或其他支持 gb2312/utf8 编码的编辑器修改这些文件，否则文件中的中文可能变乱码
搜索： LogPixels
找到的行应该是
[System\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts]
将其中的：
"LogPixels"=dword:00000060
改为：
"LogPixels"=dword:00000070
搜索： FontSubstitutes
找到的行应该是：
[Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes]
将其中的：
"MS Shell Dlg"="Tahoma"
"MS Shell Dlg 2″="Tahoma"
改为：
"MS Shell Dlg"="SimSun"
"MS Shell Dlg 2″="SimSun"
把下面的代码保存为 zh.reg
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"Arial"="simsun"
"Arial CE,238"="simsun"
"Arial CYR,204"="simsun"
"Arial Greek,161"="simsun"
"Arial TUR,162"="simsun"
"Courier New"="simsun"
"Courier New CE,238"="simsun"
"Courier New CYR,204"="simsun"
"Courier New Greek,161"="simsun"
"Courier New TUR,162"="simsun"
"FixedSys"="simsun"
"Helv"="simsun"
"Helvetica"="simsun"
"MS Sans Serif"="simsun"
"MS Shell Dlg"="simsun"
"MS Shell Dlg 2"="simsun"
"System"="simsun"
"Tahoma"="simsun"
"Times"="simsun"
"Times New Roman CE,238"="simsun"
"Times New Roman CYR,204"="simsun"
"Times New Roman Greek,161"="simsun"
"Times New Roman TUR,162"="simsun"
"Tms Rmn"="simsun"
终端执行
WINEPREFIX=~/Wine/WeChat regedit zh.reg
WINEPREFIX=~/Wine/WeChat2 regedit zh.reg
完成以上的操作，中文就显示出来了。
主要还是 riched20 的问题。我这边的解决办法是直接把 win7 的这个文件拷贝过来。 C:\WINDOWS\System32\riched20.dll ，拷贝到wine下相关的位置。要注意先给原文件做个备份。
然后重启电脑。
因为有两个微信，还是要制作不同的图标，以下是我的设置。
文件 wechat.desktop:
[Desktop Entry]
Name=WeChat
Exec=env WINEPREFIX="/home/kelu/Wine/WeChat" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/kelu/Wine/WeChat/dosdevices/c:/ProgramData/Microsoft/Windows/Start\\ Menu/Programs/WeChat/WeChat.lnk
Type=Application
StartupNotify=true
Path=/home/kelu/Wine/WeChat/dosdevices/c:/Program Files/Tencent/WeChat
Icon=8A76_WeChat.0
StartupWMClass=wechat.exe
文件 wechat2.desktop:
[Desktop Entry]
Name=WeChat2
Exec=env WINEPREFIX="/home/kelu/Wine/WeChat2" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/kelu/Wine/WeChat2/dosdevices/c:/ProgramData/Microsoft/Windows/Start\\ Menu/Programs/WeChat/WeChat.lnk
Type=Application
StartupNotify=true
Path=/home/kelu/Wine/WeChat2/dosdevices/c:/Program Files/Tencent/WeChat
Icon=8A76_WeChat.0
StartupWMClass=wechat.exe
分别给这两个文件赋予可执行权限：
chmod +x wechat.desktop
chmod +x wechat2.desktop
在桌面点击图标后，信任该文件，就可以看到图标了。
最近因为一些原因将办公操作系统由 Windows 改为 Linux。 由于已经在 Debian 9下开发了小半年时间，索性还是以Debian 9 作为办公系统。接下来会有一系列的相关文章记录这个过程。这篇文章记录我在笔记本 Thinkpad X270 上安装 Debian 9 的过程。其他版本的大同小异。
注意安装时要使用网线安装，默认没有 wifi 驱动，需要后面手动安装。另外一开始也没有触摸板的驱动，所以使用ui界面安装时候需要把鼠标插上。
官网上获取最新镜像地址：https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/
准备一个空的U盘用来刻录 debian 的系统，8G就足够用了。
推荐使用 rufus 烧录镜像。
![[rufus screenshot]](https://cdn.kelu.org/blog/2021/05/rufus_en.jpg)
这里简单涉及笔记本 UEFI 、Legacy UEFI+Legacy启动的区别了。
uefi是新式的BIOS，legacy是传统BIOS。在UEFI模式下安装的系统，只能用UEFI模式引导；
同理，如果在Legacy模式下安装的系统，也只能在legacy模式下进系统。
在目前的系统运行方式中，win8/win10 基于UEFI方式启动，其余均为Legacy方式启动。
因此，我们需要修改笔记本默认引导方式由 UEFI 改为 Legacy。
按电脑电源按钮（或重启）
不同电脑进入BIOS的快捷键不同，通常为F1、F2、DEL、ESC等，根据提示操作把。针对 X270，开机狂按 Enter 就可以选择进入 BIOS了。
关闭安全启动
对于有些主板来说，只有 把Secure Boot Control 设置为 Disable 的时候才能把 Launch CSM选项设置为Legacy。对于 Thinkpad X270 来说是如此。
设置为 disable。只有关闭了安全登陆，才可以更改 BIOS 引导为 Legacy
修改 Legacy 为优先启动顺序。
最后可以修改加载磁盘顺序，也可以在启动的时候狂按 Enter 键后手动选择。
这一块没有什么特别好说的，一路按照提示安装就可以了。
关于 Debian 在不同硬件上的安装，其实可以参考官方 wiki 中的介绍：https://wiki.debian.org/InstallingDebianOn/Thinkpad/X270/sid，官方已经对硬件进行了测试，可以细看 wifi 相关的描述， Only works with a non-free driver and or firmware：
往下翻：
关键字出来了： iwlwifi –Debian Wiki，英特尔 Wi-Fi 设备的专有驱动程序。
在 /etc/apt/source.list 里追加：
# Debian 9 "Stretch"
deb http://httpredir.debian.org/debian/ stretch main contrib non-free
安装：
apt update
apt install firmware-iwlwifi
reboot
完成。
性能测试发现业务进程运行在容器中比业务进程运行在宿主机上吞吐量下降了 100 倍，这让周一显得更加阴暗。
最近参与的项目是基于 OpenStack 提供容器管理能力，丰富公司 IaaS 平台的能力。日常主要工作就是在开源的 novadocker 项目（开源社区已停止开发）基础上进行增强，与公司的其他业务组件进行对接等。
周末给下游部门的 IaaS 平台进行了一次升级，主要升级了底层操作系统，基本用例跑通过，没出现什么问题，皆大欢喜。
结果周一一到公司就传来噩耗，性能测试发现业务进程运行在容器中比业务进程运行在宿主机上吞吐量下降了 100 倍，这让周一显得更加阴暗。
先找下游了解了下业务模型，他们说已经把业务模型最简化了，当前的模式是：业务进程运行在容器中，通过与主机共享 IPC namespace 的方式来使用共享内存与宿主机上的 Daemon 进程进行通信，整个过程不涉及磁盘读写、网络交互等。
撸起袖子开始干，定位第一步，当然是找瓶颈了，分析下到底问题出在哪。
用到的第一个命令自然是 top，top 是 linux 里一个非常强大的命令，通过它基本上能看到系统中的所有指标。
.jpg)
上面是 top 命令运行时的一个示意图，比较重要的指标都已经标了出来：
1 处表示系统负载，它表示当前正在等待被 cpu 调度的进程数量，这个值小于系统 vcpu 数（超线程数）的时候是比较正常的，一旦大于 vcpu 数，则说明并发运行的进程太多了，有进程迟迟得不到 cpu 时间。这种情况给用户的直观感受就是敲任何命令都卡。
2 处表示当前系统的总进程数，通常该值过大的时候就会导致 load average 过大。
3 处表示 cpu 的空闲时间，可以反应 cpu 的繁忙程度，该值较高时表示系统 cpu 处于比较清闲的状态，如果该值较低，则说明系统的 cpu 比较繁忙。需要注意的是，有些时候该值比较高，表示 cpu 比较清闲，但是 load average 依然比较高，这种情况很可能就是因为进程数太多，进程切换占用了大量的 cpu 时间，从而挤占了业务运行需要使用的 cpu 时间。
4 处表示进程 IO 等待的时间，该值较高时表示系统的瓶颈可能出现在磁盘和网络。
5 处表示系统的剩余内存，反应了系统的内存使用情况。
6 处表示单个进程的 cpu 和内存使用情况。
使用 top 命令查看了下系统情况，发现一切正常。load average 也不高，task 也不多，cpu 和内存都还很空闲，就连 IO 等待时间都很低，也没有哪个进程的 cpu 和内存使用率偏高，一切都很和谐，没有瓶颈！
当然，没有瓶颈是不可能的。由于我们的容器都是绑核的，所以很有可能是分配给容器的那些核是处于繁忙状态，而由于总核数较多，将 cpu 的使用率给拉了下来。于是又按下了“1”键，切换到详细模式下：
.jpg)
在这种模式下，可以看到每个 vcpu 的使用情况。一切依然很和谐，诡异的和谐。
看来从 cpu 这块是看不出来什么了，那就继续看看是不是磁盘搞的鬼吧。
iostate 命令是用来查看磁盘使用情况的一个命令，经验告诉我们，磁盘和网络已经成为影响性能的最大嫌疑犯。
.jpg)
使用 iostate 工具时，通常只用关注最后一行（%util）即可，它反映了磁盘的繁忙程度。虽然下游部门已经说了他们跑的用例是一个纯内存的场景，不涉及磁盘读写。但是客户的话信得住，母猪也能上树，我还是要跑一下 iostate，看下磁盘情况怎么样。结果，依旧很和谐，磁盘使用率基本为零。
后面还尝试了观察网络指标，发现确实也没有网络吞吐，完了，看来问题没那么简单。
虽然周一看似白忙活了一天，但是也得到了一个重要结论：这个问题不简单！不过简单的在资源层面时分析不出来啥了，得寄出性能分析的大杀器——perf 了。
perf 是 linux 下一个非常强大的性能分析工具，通过它可以分析出进程运行过程中的主要时间都花在了哪些地方。
之前没太使用过 perf，因此刚开始进行分析，就自然而然地直接使用上了 perf+ 火焰图这种最常见的组合：
安装 perf。
yum install perf
下载火焰图工具。
git clone https://github.com/brendangregg/FlameGraph.git
采样。
perf record -e cpu-clock -g -p 1572（业务进程 id）
一段时间（通常 20s 足够）之后 ctrl+c，结束采样。
用 perf script 工具对 perf.data 进行解析。
perf script -i perf.data &> perf.unfold。
PS：如果在容器中运行的程序有较多的依赖，则该命令解析出来的符号中可能会有较多的“Unregistered symbol…”错误，此时需要通过--symfs参数指定容器的rootfs位置来解决该问题。获取容器rootfs的方法根据 docker 的 storagedriver 的不同而有所不同，如果是device mapper类型，则可以通过 dockerinspect 找到容器的rootfs所在位置，如果是overlay类型，则需要通过 dockerexport 命令将该容器的rootfs导出来，如果是富容器的话，一般都有外置的rootfs，直接使用即可。
将 perf.unfold 中的符号进行折叠。
./stackcollapse-perf.pl perf.unfold &> perf.folded
最后生成 svg 图。
/flamegraph.pl perf.folded > perf.svg
最后就能得到像下面这种样子的漂亮图片。通常情况下，如果程序中有一些函数占用了大量的 CPU 时间，则会在图片中以长横条的样式出现，表示该函数占用了大量的 CPU 时间。
.jpg)
然而，perf+ 火焰图在这次并没有起到太大的作用，反复统计了很多次，并没有出现梦寐以求的“长横条”，还是很和谐。
perf+ 火焰图并没有起到很好的效果，就想换个工具继续试试，但是找来找去、请教大神，也没找到更好的工具，只好继续研究 perf 这个工具。
perf 除了上面提到的 record（记录事件）、script（解析记录的事件）命令之外，还有其他一些命令，常用的有 report（与 script 类似，都是对 perf record 记录的事件进行解析，不同之处在于 report 直接解析程序中的运行热点，script 的扩展性更强一点，可以调用外部脚本对事件数据进行解析）、stat（记录进程一段时间之内触发的事件数）、top（实时分析程序运行时热点）、list（列出 perf 可以记录的事件数）等命令。
这些命令挨个试了个遍，终于在 perf stat 命令这块有了突破：
使用 perf stat 对业务进程运行在物理机和容器上分别进行统计，发现业务进程运行在容器中时，大部分事件（task-clock、context-switches、cycles、instructions 等）的触发次数是运行在物理机上时的百分之一。
这是什么原因呢？一定是什么东西阻塞住了程序的运转，这个东西是什么呢？
前面已经分析了，不是磁盘，不是网络，也不是内存，更不是 cpu，那还有什么呢？？
是什么原因阻塞住了程序的运转呢？百思不得其解，百问不得其解，百猜不得其解，得，还是得动手，上控制变量法。
运行在容器中的程序和运行在物理机上有什么区别呢？我们知道，docker 容器 =cgroup+namespace+secomp+capability+selinux，那么就把这些技术一个个都去掉，看到底是哪个特性搞的鬼。
在这 5 个技术中，后三个都是安全相关的，都有开关可以控制，经过测试，发现把后三个都关掉之后，性能还是很差，说明这 3 个技术是无辜的，开始排查 cgroup 和 namespace。
首先怀疑的当然是 cgroup，毕竟它就是做资源限制的，很有可能一不小心限制错了，就把业务给限制了。
cgexec 是 cgroup 提供的一个工具，可以在启动时就将程序运行到某个 cgroup 中，因此我们可以将业务程序运行在物理机上，但是放到业务容器所在的 cgroup 中，看看性能会不会下降。
具体用法如下：
cgexec -g *:/system.slice/docker-03c2dd57ba123879abab6f7b6da5192a127840534990c515be325450b7193c11.scope ./run.sh
通过该命令即可将 run.sh 运行在与容器 03c2dd57 相同的 cgroup 中。在多次测试之后，发现这种情况下，业务进程的运行速度没有受到影响，cgroup 被洗白，那么真相只有一个——凶手就是 namespace。
虽然说凶手已经确定是 namespace，但是 namespace 家族也有一大票人，有 ipc namespace、pid namespace 等等，还需要进一步确定真凶。
nsenter 是一个 namespace 相关的工具，通过它可以进入某个进程所在的 namespace。在 docker exec 命令出现之前，它唯一一个可以进入 docker 容器的工具，在 docker exec 出现之后，nsenter 也由于其可以选择进入哪些 namespace 而成为 docker 问题定位的一个极其重要的工具。
通过如下命令，即可进入容器所在的 mount namespace。
nsenter --target $(docker inspect --format '{{.State.Pid}}' 容器 id) --mount bash
同理，通过如下命令即可进入容器所在的 IPC namespace 和 pid namespace。
nsenter --target $(docker inspect --format '{{.State.Pid}}' 容器 id) --ipc --pid bash
在不断的将业务进程在各个 namespace 之间切换后，终于进一步锁定了真凶：mount namespace。测试发现，一旦将业务进程放置到容器所在的 mount namespace，性能就会急剧下降。
这是为什么呢？这是为什么呢？mount namespace 到底做了什么，会有这么大的影响？
离开公司时已经时 12 点，隔壁工位的专家还在那电话会议，“我看哈，这一帧，在这个节点还是有的，但是到了这呢，就没了，它。。”，“那是找到丢包原因了？”，“别急嘛，我慢慢看，看这个节点。”。
在回家的出租车上，想想这个问题已经四天了，想想隔壁工位的专家都要成神了，还是会遇到棘手的问题，突然有种崩溃的感觉，费了九牛二虎之力猜把眼泪憋回去，不然还真怕吓着出租车师傅。
周五
早上起床还和女朋友谈起这事，说我最近遇到了一个大难题，想想已经好多年没遇到这么难搞的问题了。上一次遇到这种级别的问题，还是大四刚进实验室的时候，那时候有个问题花了一整周的时间才解决。要是今天我还解决不了这个问题，就破记录了。
记得当时是需要在实验室搭建 eucalyptus 集群，之前每次搭建都很顺利，但是那次却奇怪，怎么都搭建不成功，研究了一周之后，才发现是因为那台服务器的 bios 时间被还原了，eucalyptus 在安装过程中发现当前时间不在自己的有效时间内（太早了），因此一直安装失败。
言归正传，mount namespace 为什么有这么大的威力呢？它到底影响什么了呢？实在想不通，就去请教了下大神，大神想了想，回了我句，试试 ldd？
ldd 是什么？
当然这句话我没去问大神，转身自己查去了。
ldd 是 list, dynamic, dependencies 的缩写，意思是列出动态库依赖关系。顿时豁然开朗，mount namespace 隔离出了自己的文件系统，所以容器内外可以使用不同的依赖库，而不同的依赖库就可能造成无数种影响。
于是开始通过 ldd 对比容器中业务进程的依赖库与宿主机上业务进程的依赖库，最终发现容器中的 glibc 库与宿主机上的 glibc 库版本不一致，很可能是这个原因导致性能下降的。
于是将容器中的 glibc 库版本替换为宿主机上的 glibc 库之后，容器内业务的性能终于恢复了，猜想得到证实。
下班回家，一身轻松！
路过隔壁工位的专家时候，他刚好起身接水，顺口问道，“怎么样，平哥，丢失的那一帧找到没？”，“嗨，别提了，继续看”
为什么容器内外 glibc 版本不一致就导致性能下降了呢？
这是和业务模型相关的，前面提到，下游的业务模型是通过与主机共享 IPC namespace 的方式来使用共享内存与宿主机上的 daemon 进程进行通信。而 glibc 在一次升级中，更新了信号量的数据结构（如下），就会导致在共享内存通信时，由于数据格式不一致，每次信号量通信都超时，从而影响了程序运行效率。
.jpg)
linux下有不少截图软件，包括
默认gnome-screenshot
Flameshot
Shutter
GIMP
ImageMagick
Deepin Scrot 基于终端的一个较新的截图工具
我的需求很简单，只要可以像微信一样截图，方便做一些简单的标注即可。
使用下来感觉在 Debian 9 上 Shutter最简单，Flameshot 编译有问题就不用了，看网络介绍Flameshot也是很不错的，如果用的Debian 10 我可能会尝试下。这篇文章简单记录 Shutter 的使用情况。
debian 9 安装简单：
apt-get install shutter
| Command | Action |
|---|---|
| shutter -s | 截取鼠标选取的区域 |
| shutter -f | 截取全屏 |
| shutter -w | 截取指定窗口 |
| shutter -a | 截取当前活动窗口 |
| shutter -s -d= |
延时 |
全部设置-> 键盘，将命令行中的命令配置为自己熟悉的快捷键：
我在使用中发现，每次冷启动都要花费不小的时间，还会显示插件更新之类的提示。索性在首选项里选择开机自动启动。