作者：wiLdGoose
发布时间：2019 年 4 月 24 日
分类：技术 Technology
暂无评论
开篇第一句，感谢马爸爸。
以前在墙外 VPS 上，不需要修改 yum 源也飞快。后来用了猪厂的 yum 源，速度尚可。当有几十台服务器需要一起管理时，时间就显得特别珍贵了。因此，我找了这个物理位置最近的 yum 源。
留下命令自己马克：
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup \
&& wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
下面这个文件没有就不换了：
mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup \
&& wget -O /etc/yum.repos.d/epel-7.repo http://mirrors.aliyun.com/repo/epel-7.repo
最后：
yum clean all && yum makecache
要不要 update 你说了算：
yum -y update
嗯，真香。
作者：wiLdGoose
发布时间：2019 年 4 月 22 日
分类：技术 Technology
暂无评论
近日，某导演发给我一个神秘的链接。不敢独享，遂发圈。因将敏感词替换成了“xxx”，结果被人误会是公然开车。打算助个力，建个镜像，以证清白。
昨日周末，用一台 GCP 的台湾 Windows 主机跑这个神秘项目的种子。经过一个下午的等待，这个神秘的高达 30G 的“file.tar”终于到手。
把存放数据的磁盘分配至另一台同机房的 CentOS 主机，fdisk -l 一下。嗯，NTFS，很酸爽。
这里用到一个叫做“NTFS-3G”的项目，下载最新的版本：
wget -c https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz
解压、编译，一气呵成。
tar xzf ntfs-3g_ntfsprogs-2017.3.23.tgz && cd ntfs-3g_ntfsprogs-2017.3.23 && ./configure && make && make install
尝试挂载：
mkdir -p /path_to_wikileaks && mount -t ntfs-3g /dev/vdb /path_to_wikileaks
报错，提示 /dev/vdb 是一整块磁盘。所以：
parted -l
得到正确挂载路径是 /dev/vdb2（是因为 NTFS 首分区保留的意思吗？），最终：
mount -t ntfs-3g /dev/vdb2 /path_to_wikileaks
搞定，/etc/fstab 略。
作者：wiLdGoose
发布时间：2019 年 3 月 6 日
分类：技术 Technology
暂无评论
我使用的是 mysqld_multi 这种实现方式，每个实例有其独立的配置文件，适合强迫症患者服用。
首先配置 MariaDB 的官方 yum 源：
vim /etc/yum.repos.d/MariaDB.repo
在新建的文件中添加：
# MariaDB 10.3 CentOS repository list - created 2018-08-28 05:47 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
这里使用的是 MariaDB 10.3，当前貌似有 10.4 版本，可自行在官网查询。
完事儿之后就可以安装 MariaDB 了，这里采用二进制文件而非源码编译：
yum -y install MariaDB-server MariaDB-client
现在我准备部署三套 MariaDB 实例，具体是：
端口：3307，对应数据目录：/data/mysql/3307；
端口：3308，对应数据目录：/data/mysql/3308；
端口：3309，对应数据目录：/data/mysql/3309。
那么先来创建每个实例对应的目录：
mkdir -pv /data/mysql/330{7,8,9}
然后将这些目录所属修改到 MariaDB 用户与用户组：
chown -R mysql:mysql /data/mysql/330{7,8,9}
初始化数据目录：
mysql_install_db --datadir=/data/mysql/330{7,8,9}/data --basedir=/usr --user=mysql
好了，创建 MariaDB 配置文件：
vim /etc/my.cnf
在新建的文件中添加：
[mysqld_multi]
mysqld = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
user = multi_admin
password = YOUR_PASSWORD
[mysqld3307]
socket = /data/mysql/3307/mariadb.sock
port = 3307
pid-file = /data/mysql/3307/mariadb.pid
datadir = /data/mysql/3307/data
user = mysql
[mysqld3308]
socket = /data/mysql/3308/mariadb.sock
port = 3308
pid-file = /data/mysql/3308/mariadb.pid
datadir = /data/mysql/3308/data
user = mysql
[mysqld3309]
socket = /data/mysql/3309/mariadb.sock
port = 3309
pid-file = /data/mysql/3309/mariadb.pid
datadir = /data/mysql/3309/data
user = mysql
到这里，已经可以启动这三个实例：
mysqld_multi start 3307-3309
接着再做一些配置，请 One By One 地来：
mysql_secure_installation -S /data/mysql/3307/mariadb.sock
mysql_secure_installation -S /data/mysql/3308/mariadb.sock
mysql_secure_installation -S /data/mysql/3309/mariadb.sock
现在我们修改 root 密码，依然是 One By One：
mysqladmin -u root -p password -S /data/mysql/3307/mariadb.sock
mysqladmin -u root -p password -S /data/mysql/3308/mariadb.sock
mysqladmin -u root -p password -S /data/mysql/3309/mariadb.sock
创建一个 SQL 文件：
vim /data/src/create_user.sql
在新建的文件中添加：
CREATE USER 'multi_admin'@'localhost' IDENTIFIED BY 'YOUR_PASSWORD';
GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost';
flush privileges;
在每个实例中执行以创建多实例管理用户，嗯，One By One：
cat create_user.sql | mysql -u root -S /data/mysql/3307/mariadb.sock -p
cat create_user.sql | mysql -u root -S /data/mysql/3308/mariadb.sock -p
cat create_user.sql | mysql -u root -S /data/mysql/3309/mariadb.sock -p
然后再创建一个 sysv 脚本：
vim /etc/rc.d/init.d/mysqld_multi
在新建的文件中添加：
mysqld_multi=/usr/bin/mysqld_multi
instance_list="3307-3309"
start(){
$mysqld_multi start $instance_list
}
stop(){
$mysqld_multi stop $instance_list
}
status(){
$mysqld_multi report
}
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status
;;
restart)
start
stop
;;
*)
echo $"Usage: $0 {start|stop|status}"
exit 2
esac
接着添加 sysv：
chkconfig --add mysqld_multi
启用服务：
chkconfig mysqld_multi on
实现开机启动：
echo mysqld_multi start 3307-3309 >> /etc/rc.local
- EOF -
作者：wiLdGoose
发布时间：2019 年 2 月 14 日
分类：技术 Technology
暂无评论
木有技术含量，仅为自己马克一下。
这里用到了 nfs 和 rpcbind 两个组件。首先在客户端与服务端机器上都安装 nfs-utils 和 rpcbind：
yum -y install nfs-utils rpcbind
服务端机器上若开启防火墙的话需添加对应规则或关闭防火墙。按顺序依次将 rpcbind 和 nfs 设置为自动启动：
systemctl enable rpcbind.service
systemctl enable nfs.service
在服务端机器上设置共享目录：
vim /etc/exports
在文件末尾追加：
/data/share 10.10.10.11(rw, sync, no_root_squash) 10.10.10.12(rw, sync, no_root_squash)
其中：
/data/share 为共享目录路径；
10.10.10.11 及 10.10.10.12 为客户端内网 IP，多个 IP 写在同一行。单个星号代表任何人。也可以是主机名，支持星号模糊匹配；
rw 为读写权限；
sync：数据暂存于内存中，而非直接写入磁盘；
no_root_squash：使用 root 身份时，其权限转换为匿名使用者，UID 与 GID 切换为 nobody 身份。
最后在服务端机器上按顺序依次启动相关服务：
systemctl start rpcbind.service
systemctl restart nfs.service
在客户端机器上查看服务端机器的共享目录：
showmount -e 10.10.10.10
然后在本机创建对应目录：
mkdir -p /share
进行挂载：
mount -t nfs 10.10.10.10:/data/share /share
并将上述挂载命令写入 /etc/rc.local 文件以实现自动挂载：
echo mount -t nfs 10.10.10.10:/data/share /share >> /etc/rc.local
这里不推荐直接修改 /etc/fstab 文件，以防止服务端出现问题或客户端与服务端之间网络出现问题时产生异常。
最后祝福各位今夜安全而愉快。
作者：wiLdGoose
发布时间：2018 年 12 月 17 日
分类：技术 Technology
尚有板凳
前阵子折腾了一个 Git 仓库迁移，觉得有必要自行马克一下。
需求背景：老的版本库在一台 Windows 主机上，用 Gitblit 搭建；我在某云用一台独立主机新搭建了一套 Gitlab，前端由另一台主机部署 Nginx 反向代理。
需求内容：将老版本库的所有仓库平滑迁移到新的版本库中。
任务拆解：部署并配置 Gitlab、创建项目仓库、镜像推送、将原先指向到 Gitblit 的域名解析修改到 Gitlab、导入账户，完成。
在一切都顺利进行的时候遇到一个大小为 2G 多的仓库，零碎文件较多，最大的单文件也就几百兆。由于我本地没有这个仓库，于是：
$ git clone https://path.to.git/repo.git
进度到 20％ 多的时候，死活就断开了，反复尝试无效：
Cloning into 'repo'...
remote: Counting objects: 27709, done
remote: Finding sources: 100% (27709/27709)
remote: Getting sizes: 100% (16855/16855)
remote: Compressing objects: 23% (69/300)
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
网上找到有人说需要更改一下 Git 客户端的上传限制大小：
$ git config http.postBuffer 524288000
或者直接修改 .gitconfig 文件，修改 [http] 段：
postBuffer = 524288000
好了，依然失败。万般无奈之下找同事 copy 了整个 Git 文件夹到我本地，修改 Git 用户配置文件，git pull，成功。接着修改配置文件到新的版本库地址，然后就是见证奇迹的时刻：
$ git push -u origin --all
Enumerating objects: 27705, done.
Counting objects: 100% (27705/27705), done.
Delta compression using up to 4 threads.
Compressing objects: 100% (12552/12552), done.
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: The remote end hung up unexpectedly
Writing objects: 100% (27705/27705), 1.97 GiB | 2.17 MiB/s, done.
Total 27705 (delta 12742), reused 27100 (delta 12209)
fatal: The remote end hung up unexpectedly
Everything up-to-date
与 clone 的时候一样，push 到一定程度就断开，反复尝试死活不行。想了半天不得其解，考虑到前端用 Nginx 做了反代，Google 之。有人说：
在服务器上面配置了 Nginx 之后，使用 Git 上传大文件的时候会出现“HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large”。
嗯，好像是找到问题了？于是修改 Nginx 的配置文件 nginx.conf，在 http 段加入：
client_max_body_size 1024m;
原文说 2m 够了，我贪心，直接加到 1024m。重启 Nginx，哈哈……特么的还是失败了。
眼睛盯着别人的仓库 URL 和我的 URL，总觉得哪里不对劲。原来 git@path.to.git/repo.git 走的是 SSH 协议，我的 https://path.to.git/repo.git 走的是 HTTP 协议。
改！一顿操作，改 sshd 端口号，配置 Gitlab 为 SSH 方式，到 Gitlab 后台对项目启用 SSH 方式，再次尝试……激动得眼泪都留下来了，成功。
结论：HTTP 协议不适合于大型项目的仓库，能走 SSH 就走 SSH 吧。
- 1
- 2
- 3
- 4
- ...
- 40
- »