CentOS更新GCC,编译BoringSSL
上回,我在《关于Nginx的SSL加密方式选择》提到了无法(预)编译BoringSSL。 当时怀疑是GCC的问题,现在已经确信是GCC的问题了。 再重述环境,环境为CentOS 6.7 x64、Kernel 2.6.32-573.7.1.el6.x86_64、CMake 2.8.12.2、GCC 4.4.7 20120313、Perl 5.10.1、Golang 1.5.1。 通过分别编译GCC 4.8…
上回,我在《关于Nginx的SSL加密方式选择》提到了无法(预)编译BoringSSL。 当时怀疑是GCC的问题,现在已经确信是GCC的问题了。 再重述环境,环境为CentOS 6.7 x64、Kernel 2.6.32-573.7.1.el6.x86_64、CMake 2.8.12.2、GCC 4.4.7 20120313、Perl 5.10.1、Golang 1.5.1。 通过分别编译GCC 4.8…
首先,博客采用了ChaCha20加密方式进行加密和验证身份。 其次,要说的是OpenSSL原生并不支持ChaCha20,作者说可能会在1.1.0版本后达成支持。 如果你想使用ChaCha20加密算法,一个就是为OpenSSL打patch(由CloudFlare提供)。另外一个选择就是使用LibreSSL或BoringSSL…
之前博客其实是以Varnish=>Nginx=>PHP(FPM-FCGI)来访问的,但Varnish不支持SSL,也就是说无法使用https。好蛋疼。。。 所以耍点小聪明,以Nginx(443)=>Varnish(80)=>Nginx=>PHP(FPM-FCGI)来访问到博客。也就是说https走Nginx,反代回Varnish,Varnish反代后端Nginx反代PHP。 画了张简单的示意图…
其实对于https,一开始我是拒绝的。没必要啊,一个小小个人博客,弄个https,这不是装逼嘛。。。 但是太多小伙伴都已经用上https,而我一直是http,已经不能愉快的玩耍了。这不,有小伙伴说赞助一个泛域名证书(GlobalSign AlphaSSL Wildcard SSL Certificate),就厚脸皮接受了…
前段时间,有个页面出现了502,查看了所有相关程序的日志都没报错。。。 感觉十分之莫名其妙,因为这个页面一直是正常的,突然间也就不行了。。。 在shell下,测试了页面的PHP脚本没问题,那就是Nginx问题了,想起Nginx的日志等级是crit。 设置日志等级成error,问题出现了: [error] upstream…
说要把 PHP 更新到5.6也不是一天两天了。前期做了很多准备,检查了所有这台 VPS 的线上项目,特别是把 PHP 所有过期代码更新为新函数。所幸没遇到坑。 然后因为最近也比较忙,每天很晚才到家,所以没有执行更新操作,经常大清晨就有人打电话来找。诶。 最近爆出 PHP 远程 DoS 漏洞,官方编号…
各位看官,请喝茶。时间过得真快,已是月底。遂水文一篇。 目前博客主要采用了Varnish+Nginx+PHP+MySQL+Memcache+Redis。 使用这个构架,最主要考虑的是Cache缓存问题,没办法,自从上了Wordpress这条船和走了PHP这条不归路,缓存变得极为重要。 不管怎说,缓存任何时候都很重要啦…
无论是作为Web服务器或其他类型程序的反向代理服务器,Nginx("engine x")都有着高性能且轻量级的优势。其特点是占有内存少,并发能力强,事实上Nginx的并发能力确实在同类型的网页服务器中表现较好。 这也使得Nginx在如今不管是存放在高配独立服务器上的大型的门户…
下面就简单以CentOS和Nginx说下,如何保护Wordpress的wp-login.php和wp-cron.php,最后会说说/wp-admin/install.php。 wp-login.php是我们Wordpress的登录文件,wp-cron.php使我们的Wordpress的定时任务执行触发文件。 首先,对于wp-login.php,可以利用Nginx做了个验证,如下操作: 1…
最近在Nginx中配置自定义header,遇到一个问题,header name含下划线,会有错误出现。 查了半天wiki,又google,发现需要在conf的http段添加: underscores_in_headers on; 使其支持header name定义中包含下划线。 当然啦,你也可以用减号替代下划线符号,来避免这个问题。