• 又拍云bug导致post请求源站抛出500时会处理成504
    又拍云bug导致post请求源站抛出500时会处理成504无评论

    0x00 发现

    这次故障是在厂里生产环境发现的,表现为:
    1. 接口遇到错误时服务器抛出500错误,但是前端迟迟拿不到响应
    2. 前段pending很久之后拿到cdn返回的504错误

    0x01 分析

    最初是认为后端对500的响应处理有问题,但是这个问题仅在生产环境上可复现,测试环境和本地开发均能够正常的返回500。
    由于项目的历史原因,并没有完善的access log可以查看,所以先发布了一版带access log的版本观察,日志也显示线上环境能够正常返回500状态码,nginx日志也证实了这一点

    后来检查服务器日志的时候发现,一旦请求发生了500错误,请求都会被重复一次,而如果请[……]

    Read more

    Read more
  • 用ZeroTier重构p2p vpn
    用ZeroTier重构p2p vpn有5条评论

    前篇

    安装

    下载地址

    全平台,支持windows\linux\osx

    windows和osx都有图形界面,瞎几把点也能会用,这里说一下linux下的用法

    以centos为例,执行官方安装脚本其实是添加了一个rpm源并且调用yum下载,也可以手工下载rpm安装
    https://download.zerotier.com/ https://download.zerotier.com/zerotier-one-x64.rpm https://download.zerotier.com/zerotier-one-x86.rpm

    官方github

    下载完成后rpm -ivh zeroti[......]

    Read more

    Read more
  • 用tinc搭建p2p vpn
    用tinc搭建p2p vpn无评论

    0x00 需求

    计划恢复炉心工艺的fmc.moe域名正常使用,但是moe域名没法备案,数据库在国内服务器上,不太想搬,于是只好把域名解析到国外服务器上,然后再反代回国。

    但是同域名反代还是会遇到备案被拦截问题,于是就需要走加密协议传输或者干脆起跨机房内网

    但是我有很多台服务器,而且几乎都是跨机房的,从ucloud到阿里云,墙外有hostker和conoha,如果用普通的vpn解决方案,所有流量都得有一台服务器中转,延迟就会几乎*2,非常糟心,于是就需要一个靠谱的p2p vpn方案。

    0x01 选型

    openvpn

    openvpn自带p2p模式,但是openvpn的p2p模式一个守护[……]

    Read more

    Read more
  • 解决logstash启动过慢的问题
    解决logstash启动过慢的问题无评论

    最近在搭elk时,发现logstash在服务器上要花费将近10分钟才能启动完成开始pipeline

    而我用的机器是ucloud的2C4G,不太可能是服务器性能的瓶颈

    查资料后发现和jruby的启动有关,于是找到了这个issue

    https://github.com/elastic/logstash/issues/5507

    提到了jruby wiki里的一段话

    When JRuby boots up, the JDK libraries responsible for random number generation go to /dev/random for (at least[……]

    Read more

    Read more
  • 记录一处discuz不兼容php7导致UCenter通信失败
    记录一处discuz不兼容php7导致UCenter通信失败无评论

    dz版本,discuz! F1.0
    UCenter的通信测试的实质,是一个script脚本,调用地址是
    /uc_server/admin.php?m=app&a=ping&inajax=1&url=https%3A%2F%2Fexample.com&ip=&appid=1&random=1230195151&sid=sdsfsddfd
    直接访问就能看到报错

    此处的代码是

    而php5到php7有一个breaking change和类方法动态调用有关

    http://p[……]

    Read more

    Read more
  • 2016年终总结
    2016年终总结有1条评论

    距离2016年结束还有不到两个星期,是时候想想今年都干了些什么了

    年初的时候由于原厂架构变更,使用rabbitmq作为消息中间件,做服务拆分和为服务化,于是搞出了carrotmq 简化官方sdk使用难度,一度爬上npm下载量前5%

    conoha服务器被封了一次,原因是翻着墙操作了在cohona的控制台充了钱,随后和客服交涉(可以用中文发,虽然回复是日文的)后解除了,但是也被告知仅此一次。

    炉心工艺从5周目开始解决了玻璃不防雨的问题,以前的问题是Bukkit下World.getHighestBloc(Position)方法会忽略透明方块,于是玻璃会被忽略从而判断玩家站在露天的地方。
    解决方[……]

    Read more

    Read more
  • 解决微博挂件不支持HTTPS导致浏览器报混合内容
    解决微博挂件不支持HTTPS导致浏览器报混合内容无评论

    由于微博挂件不支持HTTPS,即使把调用的网址改成https的,也会由于返回的页面里引用的内容全部都是http而报混合内容。但是其实手工访问每个引用内容,都是支持HTTPS的,但是新浪太坑,全部按照http返回了。

    最近突然在Chrome的开发者工具里看见了所有https请求都会携带一个Upgrade-Insecure-Requests:1头,Google后发现这个头允许浏览器自动升级http协议到https协议,对应的需要让服务端发来一个Content-Security-Policy: upgrade-insecure-requests,就可以让浏览器自动升级协议了。

    https

    于是在ngin[……]

    Read more

    Read more
  • 修复cnpm install命令回退npm而不是使用npminstall进行快速安装
    修复cnpm install命令回退npm而不是使用npminstall进行快速安装无评论

    终于受不了npm的安装速度了,每次发布的耗时都能吃顿饭,让运维配合更换cnpm后查看输出日志却还是npm的格式,而不是npminstall的格式。

    运维给出了服务器上的执行脚本

    看上去并没有什么问题,本地带相同的参数也能够正常调用npminstall。

    怀疑cnpm版本问题,但是运维给出cnpm -v是4.4.0

    后来在postinstall的hook里输出process.env,发现有shrinkwrap的设置,而npminstall是不支持shrinkwrap的,但是本地即使添加shrinkwrap也不会让cnpm[……]

    Read more

    Read more
  • nodejs CorkedRequest导致内存泄露
    nodejs CorkedRequest导致内存泄露无评论

    0x00 状态

    有一个websocket长连接服务原先是用php的workerman框架跑的,但是近期出现了一些莫名其妙的bug,用Nodejs重写后接替了原先的全部流量。
    最初还没什么问题。
    跑了一段时间后发现内存泄露问题比较严重,服务器有8G内存,用cluster方式跑了8个进程,几乎24小时内就会吃满8g内存,导致进程被系统kill。

    0x01 堆内存分析

    遇到内存泄露,第一时间想到的就是把内存dump下来看看,于是发布了一个能够实时dump内存的版本,拿到heapdump文件后发现文件只有60M不到,而当时的进程内存占用达到了1.6G,于是能够知道大量的内存开销都不是堆内存,而是[……]

    Read more

    Read more
  • CentOS 7 下MariaDB修改datadir后无法启动
    CentOS 7 下MariaDB修改datadir后无法启动无评论

    前阵子想把服务器的CentOS 6.8升级上CentOS7。但是失败了,重装了系统

    重装以后挂载好数据盘后发现MariaDB起不来了,查journal log,只有一行warning

    can’t create test file /var/lib/mysql/core.lower-test

    google了一下,有两种方案

    第一是说selinux导致的,但是ucloud的镜像默认就是关闭selinux的,所以不是这个问题

    第二说是apparmor限制了进程的目录读写,但是那是Ubuntu下默认安装的,CentOS下没有这个东西,所以也不是这个问题。

    其他文件权限之类的都检查过了,而且[……]

    Read more

    Read more

Back to Top