在我记忆中，CentOS 从很早开始，就没有和各种的问题挂钩过。得益于它保守的升级策略，它自己几乎从来不是问题专业户，我对它的印象更多是因为太过保守导致的库升级不及时问题。 可是最近，CentOS7 某个版本发行之后，偶尔的，会出现 supervisor 拉 redis 失败的问题。从日志的内容来看，全是 Permission denied 相关的问题，bind socket 的时候权限不够，write log 的时候权限不够，dump snapshot 的时候权限不够，只要跟写磁盘相关的，都有这个问题。 单独执行 /usr/bin/redis-server /etc/redis.conf，又一点儿问题没有，命令本身没有问题，一切正常。 关键，supervisor 是以 root 去拉 redis 的啊！表示很无辜 (o´・ェ・｀o) supervisor 的配置如下： [program:redis] command = /usr/bin/redis-server /etc/redis.conf ;process_name=%(program_name)s ; process_name expr (default %(program_name)s) numprocs=1 ; number of processes copies to start (def 1) directory=/data ; directory to cwd to before exec (def no cwd) ;umask=022 ; umask for process (default None) ;priority=999 ; the relative start priority (default 999) autostart=true ; start at supervisord start (default: true) autorestart=true ; whether/when to restart (default: unexpected) startsecs=1 ; number of secs prog must stay running (def.……

2017-08-17 更新：因为服务器到期，下述方法已经失效。加速的方法请参照这里的方法设置 composer 镜像源，并使用下面的方式创建项目。 composer create-project --prefer-dist laravel/laravel [project_name] 这样创建项目时，将使用镜像源下载框架，而不会从墙外的 cabinet.laravel.com 下载。 前段时间有个项目用到了 laravel 框架。laravel 本身是个很优秀的框架，OOP 的思想贯穿始终，大量使用已经开源的第三方类库，用反向控制（IoC）的思想对服务进行抽象和隔离，帮助程序员完成对服务的分治，大大提高了架构效率和开发效率、后期维护效率。 laravel 目前最新的稳定版是 laravel 5.1。因为我是从 5.1 开始使用 laravel 的，对 5.0 及 4.x 版本并不熟悉。但从网上大家的反馈来看，laravel 4.x 的使用方法和 5.x 相差较多，甚至 5.0 和 5.1 在细节处也有很多大的改进。我这里针对的主要是使用 laravel 5.1 的朋友，下面如果未明确提及版本，也默认指代 laravel ^5.1。 laravel 中新建项目的方法如下： laravel new [project_name] 但是这个命令很慢，原因在于每次执行这个命令，laravel installer 都会从 http://cabinet.laravel.com/latest.zip 下载最新的稳定版 laravel 空项目代码，用以创新新项目。 # ~/.composer/vendor/laravel/installer/src/NewCommand.php (Line.97) // ...... /** * Download the temporary Zip to the given file.……

推荐一篇文章《解读Cardinality Estimation算法》。 文章讲得很酷，还附带了一个电商数据统计的实际应用案例。 鉴于文章写得太好，明显是博主原创，所以我就不转载了，大家直接光顾原处看吧。下面是系列文章的目录： 解读Cardinality Estimation算法（第一部分：基础概念） 解读Cardinality Estimation算法（第二部分：Linear Counting） 解读Cardinality Estimation算法（第三部分：LogLog Counting） 解读Cardinality Estimation算法（第四部分：HyperLogLog Counting 和 Adaptive Counting） 另外，作者还有一篇《网站统计中的数据收集原理及实现》的科普文章，同样不错，有想了解数据统计基础原理的同学也可以看看。……

用了好几年的 gitlab，前前后后搭建了好几次系统，解决了不少问题，还是非常熟悉了。昨天又遇到 gitlab 搭建中的一个新的问题。 现象 gitlab 搭建好之后，建账号，加 ssh key，建项目，本地 push，然后就遇到 gitlab 问我要密码。 git@some.domain.name password: 项目是我创建的，ssh key 也有添加，还找我要密码，明显不科学。 尝试解决 首先，检查了服务器的 sshd 设定，确认启用了 ssh 登录。 cat /etc/ssh/sshd_config | grep PubkeyAuthentication PubkeyAuthentication yes 以为是缓存，分别重启了 redis 和 gitlab。（PS：我的 redis 用 supervisor 管理起来的） supervisorctl restart redis service gitlab restart 然后等了五分钟再试（其实没有必要），还是不行。 上网查，stackoverflow 上有一个非推荐答案说，重启服务器之后就好了。于是，又重启了服务器。 shutdown -r now 还是不行…… 用 ssh -T 命令测试一下，看看结果。 ssh -vvvT git@some.domain.name …… 一串无关的日志我就省略了，只说重点。 …… debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password git@some.……

有这么割裂和相互冲突的产品功能，有这么拙劣的安全事故应对机制，有这差的客户服务，还秉承了做安全『就是让你改不了密码和个人信息』的核心思想…… 就连想安安静静收发个邮件都不让了。网易邮箱已死，有事，请烧纸。 前段时间传出网易邮箱被拖库以后（科普：什么是拖库），我咨询过网易邮箱内部的资深人士，结果发现他们也不知道具体什么情况。从一开始跟我说不可能骂乌云不厚道，到后来让我赶紧去改密码，他们在网易邮箱内部工作的，比我这个外人还警醒得晚。网易邮箱有些事情把上下里外都瞒得棒棒哒，实际怎么样没人能知道。 当初为了所谓『安全』，网易邮箱引导我设置了生日及密码问题、保密邮箱、关联手机、安全码，还引导我申请了密保卡（8X8 矩阵那种），设置了身份信息、关联了手机，最近还申请了结果修改个密码都只能去走『申诉』途径。 我用邮箱无非希望（一）安全（二）无遗漏（三）服务稳定（四）收发及时，其余都属于次要需求。网易现在第一点没保证，第三点不能提供，四点要求出脱一半。关键是，我们还有可替代的方案。网易邮箱不死没天理。 实在不知道网易到底要跟时代脱节到什么地步，到现在了，还固步自封在自己的小世界里，想着跟用户做生意吗？！ 只能从此不再用网易邮箱。……

用 gitlab 很长一段时间了，从 2013 年开始，一直到现在，在每一个团队中都在推广使用 gitlab-ce 做版本管理和项目管理。本来一切好好的，一直到今天。 今天我要做备份的时候。 sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production 命令不灵了。 Dumping database … Dumping MySQL database gitlabhq_production … [FAILED] Backup failed 谷歌了解决办法，无非下面几个情况： 没有装 mysql client library。 解决办法：安装一个 mysql client library 就好。 git 用户没有写入 config/gitlab.yml 中设定的备份目录的权限 解决办法：修改备份目录所有者为 git 用户就好。 官网上有 issue 是关于 PostgreSQL 的，没有结论，参考价值不大 我挨个排查了一下，上面几种情况都排除了。 首先，我的 gitlab 站点完全正常访问， 所以第一种情况可以排除。 其次，tmp/backups/db/ 目录下还有一个空文件 database.sql，我删除之后再试，它还能生成，证明备份 DB 的效果是有的，就是不知道为什么，没有取到 DB 里面的内容，备份成空文件了。顺便检查了下备份目录的磁盘空间，完全充足，用下面的命令证明 git 写入文件到备份目录是完全没有问题的。……

Angularjs 是伟大的 Google 贡献的 JS 框架。自问世以来，angularjs 以其独特的开发思维方式鹤立于 web 前端开发的圈子，并且以其出众的实际效果赢得大家的喜爱。 Angularjs 自己提供了一整套的学习文档、设计文档、会议材料等等资料，帮助大家逐步深入了解和学习。可惜这些资料存放在谷歌自己的云盘（Google Drive）中，因为一些众所周知的原因，很不方便下载。我在这里把这些资料打包放在这里，以备不时之需，希望对大家有用。 Angular_Public_Design_Docs_And_Notes-2015-10-26（七牛空间失效） PS：最爱 Google 系的一点就是不论是库、框架还是业务代码，文档总是有的，你能从中了解到工程师的初衷和思路，加以消化学习。哈哈！……

最近遇到一个比较搞的问题，有关 linux 下的文件权限。因为发现解决问题之后的答案是我们很多工作多年的攻城狮以前都没有重视过的，所以特别写下来，帮助加深记忆。 【背景】 同事学习 lnmp，搭好 CentOS 6.5 的环境之后，新建了一个用户组 test，在该组别下新建了一个用户 test，然后准备用这个用户模拟 nginx 和 php-fpm 进程的启动用户，跟着手册上做实践。 【关键信息】 用户：test:test 目录：/www/test 目录权限：drwxrwxrwx. 2 root root 40 Oct 21 16:43 test 文件：/www/test/index.html 文件权限：-rw-r--r--. 1 root root 0 Oct 22 10:04 index.html 【现象】 先用 root 的身份 touch 了一个空文件 index.html； su test，然后以 test 用户的身份去删除这个空文件； WTF！！！ 竟然删除文件成功了？？？！！！ 普通用户删除了 root 用户的文件，我保证，刚看到这个现象的时候，我内心绝对是崩溃的。 【解决的途径】 首先，检查了 test 用户的用户组，确认的确是 test 组。 其次，检查文件和目录的权限，除了 test 目录没有按照惯例，被设置成 0777 之外，没有什么特别的。不可能一个 0777 还能捣蛋吧？！……

……

……