Docker 快速开始与基本用法
本人不是 docker 重度用户，也不是从事运营 docker 或 k8s 相关工作的运维人员。我使用 docker 通常是偶尔试一些东西，避免把服务器环境搞乱；或者是想在一个相对干净的环境中临时编译一个项目等。所以我属于比较轻度的 docker 用户，基本上也就只会用到一些基础功能。本文也不会介绍相对复杂的 Dockerfile 配置。
本文的主要目标是：
从 0 快速启动一个 docker 容器，并使用 ssh 登录该容器。
给出一些 docker 比较常用的操作和容器配置（至少是作为轻度用户的我比较常用的）。
本文使用的 Linux 发行版为 CentOS 8。
另外，docker 的安装和使用默认需要 root 权限，如果你需要在没有权限的用户里使用 docker，请查阅官方文档。
1. 安装 Docker1.1. 卸载旧版本 Docker旧版本的 docker 的包名叫做 docker 或者 docker-engine，我们需要把旧版本的 docker 卸载掉（如果有的话）：
12345678sudo yum remove docker \ ...
Linux 配置 V2Ray 和 ProxyChains 实现命令行代理（无图形界面）
我在国内的服务器上进行某些操作的时候常常会被因为网络问题困扰，于是决定配置一下代理。
注意下本文是在没有图形界面的 Linux 上进行的，如果你用的是带图形界面的 Linux，网络上有更多更合适的文章。
本文适合已经有 V2Ray 结点的同学（无论是自建的还是别人现成的）。
1. 安装并配置 V2Ray1.1. 安装 V2Ray执行下面的命令安装（更新也可）V2Ray：
1sudo bash <(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh)
这个执行的脚本里面会有在 GitHub 下载 v2ray-core 的 release 版的操作，所以可能会比较慢。
另附卸载 V2Ray 的命令：
1sudo bash <(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh) --remove
1.2. 修改配 ...
Linux 配置 ProxyChains 本地代理
为了在 Linux 中使用命令行代理，本文介绍如何安装并配置 ProxyChains 本地代理。
ProxyChains 在 GitHub 上开源，项目地址：proxychains-ng。
配置成功后，只需要在需要走代理的命令前加上 proxychains 即可，例如：
12$ proxychains curl www.google.com$ proxychains git clone git@github.com:gukaifeng/hexo.git
简单好用，下面说用法。
1. 安装 ProxyChains首先克隆项目到本地，并进入目录：
12git clone git@github.com:rofl0r/proxychains-ng.gitcd proxychains-ng
配置：
1./configure --prefix=/usr --sysconfdir=/etc
编译安装（需要系统内有 C 编译器，最好是 gcc）：
12makesudo make install
安装完成后，在命令行输入 proxychains4 （应当已经可以自动补全了）可以看到以下内容： ...
Linux 一键更换国内软件源
通常我是在自己的 Linux 机器上配置代理的，但是确实也有很多场景配置代理是不容易操作的。
为了能顺利安装一些软件，也只能是换国内软件源咯。
更换国内软件源这件事有大佬编写的脚本我们可以拿来直接用，项目地址是 GitHub 或 Gitee。
基本上各种主流的 Linux 发行版都能用，这里就不多说了，更详细的信息可以看项目地址。这里直接说咋用。
用法非常简单：
12wget https://gitee.com/SuperManito/LinuxMirrors/raw/main/ChangeMirrors.shsudo sh ChangeMirrors.sh
即可进入脚本提供的交互界面，像下面这样：
123456789101112131415161718192021222324252627282930313233343536373839+---------------------------------------------------+| || ================ ...
在 VSCode 中配置使用 CMake 的 Linux C/C++ 开发环境
本文默认你已经有在 VSCode 中配置 Linux C/C++ 开发环境的经验。前置微软官方文档 Gcc on Linux。我们知道，在配置 C/C++ 的常规方法中，VSCode 会在项目目录中生成一个名为 .vscode 的隐藏文件夹，里面放着一些相关的配置 json 文件。其中与 C/C++ 环境开发有关的主要有三个：
task.json：编译器的编译相关配置。例如编译命令、编译参数设置等等。
launch.json：调试相关的配置。例如调试器路径、调试目录配置等。
c_cpp_properties.json：编译器路径和智能提示(Intellisense)设置。例如 C++ 版本、用于智能提示的头文件路径设置等。
而如果使用 CMake 的话，我们就只需要配置 CMakeLists.txt 文件（可能是多个）就可以了。
本文用于在 VSCode 中配置使用 CMake 的 Linux C/C++ 开发环境的快速入门，关于更深入的内容，建议看：
CMake Tools for Visual Studio Code document ...
如何创建一个 Linux RPM 包
这篇文章包含以下内容：
什么是 RPM 包。
如何创建一个 RPM 包。
如何安装(install)、查询(query)、移除(remove)一个 RPM 包。
RPM 相关功能非常强大，并非一篇文章所能涵盖，本文相关内容仅用于入门。如果你有本文没有提到的、更复杂的需求，建议参考官方指导：RPM Packaging Guide。
1. 什么是 RPM 包？RPM 全称 Red Hat Package Manager，即红帽包管理器，这是一个由 Red Hat 开发，主要用在基于红帽的操作系统上的（如 Fedora、CentOS、RHEL 等）。
RPM 包使用 .rpm 扩展名，是一个不同文件的捆绑包（一个集合），其可以包含以下内容：
二进制文件，也就是我们常说的可执行文件（如 nmap、stat、xattr、ssh、sshd 等）。
配置文件（如 sshd.conf、updatedb.conf，logrotate.conf 等）。
文档文件（如 README、TODO、AUTHOR 等）。
RPM 包的文件名格式如下：
1<name>-<version& ...
我的 Vim 常用配置与命令笔记
首先说明呢，我并不是 vim 的深度用户，我只是经常 ssh 到远程机器上编辑一些文件什么的，这时候 vim 就顺手用了。
所以呢，这篇文章记录的也都是些简单的东西，vim 高级功能我也用不上。
1. vim 常用配置记录我的常用配置呢，主要就是每当我登录一个新机器并且需要使用 vim 的时候，可以把这里的配置直接 copy 一份省时省力 ~
当然我还是会说明每个配置项是干啥的。
vim 的配置文件有两个，一个是全局的，在 /etc/.vimrc，一个是用户级的，在 ~/.vimrc，用户级的优先级高。
编辑哪个都可以，这里就编辑用户级的 ~/.vimrc 了（不过如果你有在非 root 用户下 sudo vim 编辑的需求的话，建议把 /etc/.vimrc 也改了）：
1vim ~/.vimrc
(注意不管是全局的还是用户级的配置文件，如果默认不存在的话，直接通过 vim 自动创建并编辑保存就好了 ~)
前面的单引号表示注释 "。
12345678910set fileencodings=utf-8,ucs-bom,gb18030,gbk,gb2312,cp936,la ...
我的 Git 常用命令笔记
1. 基础命令修改本地分支名字：
1git branch -m <old_branch_name> <new_branch_name>
修改后会与关联的远程分支失去联系，首次 push 需要指定远程分支，一般在你首次 push 的时候会给你个提示，告诉你怎样做，好解决。
比如我将本地的 master 分支改名为 main，然后首次 push 应当这样：
1git push origin HEAD:master
这样会将本地的 main 分支与远程的 master 分支关联，就可以正常使用了。
修改本地分支关联的远程分支：
1git branch --set-upstream-to=<remote_rep_name>/<remote_branch_name> <local_branch_name>
例如：
1git branch --set-upstream-to=origin/main main
将本地分支 main 的与远程仓库 origin 的 main 分支关联。
2. 场景2.1. 关于贮藏下面的所有列出场景都 ...
解决 CentOS 中 LD_LIBRARY_PATH 配置正确却找不到动态链接库的问题
今天遇到一个很离谱的问题，场景如下：
运行某可执行程序时，提示某动态库找不到，错误如下：
1libxxx.so: cannot open shared object file: No such file or directory
通过 ldd 命令查看可执行程序的链接库，可以得到其确实没有找到此库：
123...libxxx.so => not found...
但在这里，我可以 100% 确定，我的 LD_LIBRARY_PATH 配置没有问题，此动态库也确实存在！
最终找出问题所在，但应当是 bug。
我们知道，动态库往往都是，有一个名字上带有详细版本号的真正的动态库文件，如 libxxx.so.7.6.0，有多个精简了版本的软连接指向前面那个真正的动态库，如 libxxx.so，libxxx.so.7，libxxx.so.7.6 等。就像下面这样：
1234libxxx.so -> libxxx.so.7.6.0libxxx.so.7 -> libxxx.so.7.6.0libxxx.so.7.6 -> libxxx.so.7.6.0libxxx ...
解决 mysqld: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found
1. 遇到的错误报告在安装/运行 mysql 时可能会遇到类似如下错误（节选）：
12345...mysqld: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by xxx)...mysqld: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by xxx)...
其他场景也可能遇到类似错误，这其实很高频，解决方法都是一样的。
2. 错误分析猜测主要原因是 GCC 的版本过低，而编译过程依赖更新版本 GCC 中的库。
以 GLIBCXX 举例，我们按如下命令我们当前 /usr/lib64/libstdc++.so.6 关联的 GLIBCXX ：
1strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX*
12345678910111213141516171819202122232425262728[gukaifeng@ ...