作者：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 * (rw, sync, no_root_squash)
其中：
/data/share 为共享目录路径；
* 星号代表任何人；
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：具备方法论，善于总结与利用一切资源
各位看看，你在哪儿？
作者：wiLdGoose
发布时间：2018 年 9 月 30 日
分类：技术 Technology
暂无评论
好久不在贵行混，殊不知原先那套 LAMP 或 LNMP 的架构早已奥特且随着岁月流逝慢慢发生了升级与变迁。
这次要玩的是一套提供前端服务的架构。大致交代一下故事背景：
1、负载机绑定了 1 个公网 IP 与 1 个私网 IP（VIP地址、私网 IP 漂移、HAProxy 高可用啥的需要运营商配合，正在准备，以后玩过了再写），部署 Nginx 用于反向代理；
2、前端服务所在主机与负载机在同一私网网段内。
好了，故事开始。
首先部署完负载机的 Nginx 服务，用于监听负载机的 TCP 80 及 443 端口。值得注意的是若使用源码编译方式安装 Nginx，记得添加：
--with-http_ssl_module --with-http_realip_module
其实直接 yum 也阔以。安装后对配置文件 nginx.conf 进行调整：
user www www;
worker_processes auto;
error_log /path/to/logs/error.log;
pid /path/to/logs/nginx.pid;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 65535;
}
http {
include mime.types;
default_type application/octet-stream;
include /usr/local/nginx/conf/reverse-proxy.conf;
sendfile on;
keepalive_timeout 65;
gzip on;
client_max_body_size 50m; #缓冲区代理缓冲用户端请求的最大字节数,可以理解为保存到本地再传给用户
client_body_buffer_size 256k;
client_header_timeout 3m;
client_body_timeout 3m;
send_timeout 3m;
proxy_connect_timeout 300s; #nginx跟后端服务器连接超时时间(代理连接超时)
proxy_read_timeout 300s; #连接成功后，后端服务器响应时间(代理接收超时)
proxy_send_timeout 300s;
proxy_buffer_size 64k; #设置代理服务器（nginx）保存用户头信息的缓冲区大小
proxy_buffers 4 32k; #proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
proxy_busy_buffers_size 64k; #高负荷下缓冲大小（proxy_buffers*2）
proxy_temp_file_write_size 64k; #设定缓存文件夹大小，大于这个值，将从upstream服务器传递请求，而不缓冲到磁盘
proxy_ignore_client_abort on; #不允许代理端主动关闭连接
server {
listen 80;
server_name _;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
记得打开防火墙端口，若还有上级网络安全策略等，更新配置。
前端机 Web 服务因人而异了，这里假定还是由 Nginx 提供前端服务，部署过程略，监听前端机的 TCP 80 端口。值得注意的是需要在 Nginx 配置文件中定义日志格式：
log_format access '$HTTP_X_REAL_IP - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $HTTP_X_Forwarded_For';
access_log /path/to/logs/access.log access;
在负载机上编辑反向代理的配置文件：
vim /usr/local/nginx/conf/reverse-proxy.conf
若有多个 server 可再行扩展：
server
{
listen 80;
server_name sub.domain.com;
location / {
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://192.168.x.x;
}
access_log /path/to/logs/sub.domain.com_access.log;
}
截至目前，http 协议的转发已经完成。域名解析完成且生效后，访问应该会从负载机走私网定向到前端机。看了一圈日志没问题后，继续折腾 https。
SSL 证书提供商毫无疑问是 Let's Encrypt。据我所知有 certbot-auto 与 acme.sh 两种方式来实现证书自动申请与续展，前者貌似只能支持单个域名，而后者目前已支持泛域名证书。因此我选择后者。
配置过程就不展开了，中文版引导在这里。值得注意的是，若使用 certbot-auto，则需要修改负载机 Nginx 的反向代理配置文件，将 .well-known 目录指向本地：
server {
listen 80;
server_name sub.domain.com;
[…]
location /.well-known {
alias /path/to/sub.domain.com/.well-known;
}
location / {
# proxy commands go here
[…]
}
}
若使用 acme.sh，则既可通过 .well-known 目录来验证，也可通过 DNS 解析来验证（需提前向域名注册商申请 API）。可参考这里。
好了，到这里，证书更新的事儿也是自动的。
去喝杯咖啡吧～
Update：
已实现客户端到负载机的访问是公网 https，负载机转发到前端机走私网 http。已遇到一个问题，最新版的 phpMyAdmin 会提示：
服务器和客户端上指示的 HTTPS 之间不匹配。这可能导致 phpMyAdmin 无法正常工作或存在安全风险。请修复您的服务器配置以正确指示 HTTPS。
嗯～有待进一步解决。
Update：
上述问题解决方案：在 phpMyAdmin 的配置文件中添加：
$cfg['PmaAbsoluteUri'] = 'https://pma.xxx.com';
即可。
作者：wiLdGoose
发布时间：2018 年 9 月 27 日
分类：技术 Technology
暂无评论
还是那堆联通云机，交付前 LVM 也不给搞好，云盘默认也不挂载，特别吐槽一下。怀念某云的傻瓜式服务，前者到底是国有，揍是硬气。
这是扩容前的情况：
[root@centos7 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 10G 10G 20K 100% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 369M 3.5G 10% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 485M 166M 319M 35% /boot
tmpfs 783M 0 783M 0% /run/user/0
用 vgs 和 lvs 看一下可用空间，并根据实际情况构造如下命令：
[root@centos7 ~]# lvresize -L +37.51G /dev/rootvg/rootlv
Rounding size to boundary between physical extents: 37.51 GiB.
Size of logical volume rootvg/rootlv changed from 10.00 GiB (2560 extents) to 47.51 GiB (12163 extents).
Logical volume rootvg/rootlv successfully resized.
最后同步一下文件系统就搞定了：
[root@centos7 ~]# xfs_growfs /dev/rootvg/rootlv
meta-data=/dev/mapper/rootvg-rootlv isize=512 agcount=4, agsize=655360 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=2621440, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2621440 to 12454912
验证：
[root@centos7 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 48G 9.8G 38G 21% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 369M 3.5G 10% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 485M 166M 319M 35% /boot
tmpfs 783M 0 783M 0% /run/user/0
自己马克一下。
- 1
- 2
- 3
- 4
- ...
- 40
- »