作者：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 吧。
作者：wiLdGoose
发布时间：2018 年 10 月 31 日
分类：观点 ViewPoint
2 条评论
这几天公司有个内部培训，讲的是产品运营。PPT 和现场录音就不放出来了，老板会打我。
这个小培训从企业与产品的概念开始，讲到产品设计的方法论，其中不乏感同身受之处，在此引用并扩展讨论。
（上班时间还能写博，就问你羡慕不羡慕？！）
产品是解决企业运作中，需要降低交易成本、解决社会问题与创造更多利润等一系列诉求的工具集。
这里的产品则是广义的产品了，一套软件系统、一场培训活动、一个营销方案都可称之为产品。诉求不同，则需要实现的目的不同，其工具集合也不同。
从这个意义看，不同的岗位都存在产品经理附身的可能性与需要性。
从想法到产品的实现，是理想模型的实例化。
从传统互联网角度来看，产品设计是：
- MRD 到 PRD 的实现；
- 继承了甲方爸爸的意愿与需求，并翻译为开发语言的过程；
- 一系列中间件；
- 底层数据的抽象。
对于产品经理（PM）或者产品设计（PD）的误区由来已久，大多是：
- 产品经理是我们的人，怎么老是帮着甲方说话，跪舔？
- 喂，吴总，你们那个产品经理不行啊，老子要实现东西他丫的全给我改了；
- 一天到晚叫我们改来改去，有毒？
- 这个产品经理不错，定稿前所有需求都会问我们能不能实现；
- 丫的，这个功能根本实现不了好嘛？！判断用户手机壳颜色变化自适应手机系统桌面主题？！丫去死^&%@$!@$#!@#
- 只有粗犷的原型，没有 PRD，简直就是耍流氓～
好了，我们来具体分析一下。
1、不尊重需求——盲目迎合需求或无视需求型
上文情况 1、2 均为此类。
- 无视需求的实质，盲目迎合。倘若需求方是甲方，实有跪舔嫌疑；倘若需求方正是自己，则为意淫；
- 漠视需求而追求结果导向，很有可能想的与做的完全不是一回事（甲方爸爸能不骂你，给你穿小鞋嘛？）。
2、缺乏思考——主观臆断需求或只传达不思考不加工需求型
上文情况 3、4 均为此类。
- 需求方说要改，你就改。神马项目进度安排、版本迭代管理，都是浮云。好吧，你有毒，你赢了；
- 我只听说过向上溯源的，向下求证也可取，但不能有倾向性。但凡事事问开发的产品经理，不是无脑就是懒。
3、需求输出不明确——自以为是的形而上学或偷工减料
上文情况 5、6 均为此类。
- 自以为是的产品经理，其人身安全往往得不到很好的保障。此观点在业内已被多次事实印证。产品设计需要强调创意创新与主观意识，但绝对不是脱离了实际可行性的胡编乱造；
- 产品设计属于需求环节还是生产环节？应该是更偏向于全局协助的角色。所谓上知天文，下知地理，也不过如此。产品设计任重而道远，不可随心所欲，偷工减料。
可见，没有可行性分析的产品设计都是耍流氓。对吧，亲？
PPT 的最后，标注了一套产品经理的升级路线。
Lv 1：关注可行性
Lv 2：具备创造能力，找到最优解
Lv 3：权衡利弊，全局考虑
Lv 4：面向变迁，考虑未来与更多的可能性
Lv 5：具备方法论，善于总结与利用一切资源
各位看看，你在哪儿？
- 1
- 2
- 3
- 4
- ...
- 39
- »