曾经的曾经，单个IP上配置多个https证书是不可以的；随着ssl的一代代的升级，得益于TLS的SNI(Server Name Indication )，现在单个IP上也可以配置多个https证书了；但是，需要client和server都支持（不过现在的浏览器或其他client都能支持了），只要sslv3或tls都可以
查看nginx是否支持多证书：
参考：
http://blog.csdn.net/cccallen/article/details/6672451
https://www.ttlsa.com/web/sni-multi-domain-virtual-host-ssl-tls-authentication/
ldap服务器端默认每次search条目数最多 500 ； 加入我的条目数最多不会超过2000，那么，我是在不想分多次来search，直接把这个限制放大是再好不过的了；配置方法：
/etc/openldap/slapd.conf 中添加：
|
1 |
sizelimit 2000 |
或者
|
1 |
sizelimit 0 |
注意: 这个限制只有管理员账号search时，才会超过500，普通账号search是不能超过500的
man ldapsearch:
国内访问不卡的github： https://coding.net/
现在都流行动态码认证了，ldap这个认证领域的老大还是静态密码认证，显得有些过时了，这里试图修改认证部分逻辑已支持动态密码验证。
相关代码： servers/slapd/bind.c
编译：
注意： make install时默认是会去掉符号信息的；添加 STRIP=” 选项就不会去掉了（可能你也不需要make install）
开始gdb：
用户名：op->o_req_dn
密码在这里： op->o_request->oq_bind->rb_cred:
下一步就是要把密码修改，其中一部分拿到别的地方做动态密码验证，剩余部分继续给ldap来验证
ldap 验证逻辑：
长连接避免了每次请求都重新建立连接，理论上是好事儿，欣然用之；后发现nginx偶尔会报如下错误：
|
1 |
.... [error] 23951#0: *121082947 readv() failed (104: Connection reset by peer) while reading upstream ... |
而且有同事A反应，调用同事B的接口时，收到了200响应码，但是没有收到响应的其他数据，而且确认不是因为超时所致；同事B反馈说，接口执行正常，应该有数据返回，而且确认接口执行速度很快，日志为证。
双方说的都对，事实却是如此，我试图模拟这种情况的出现，模拟办法：
让接口输出响应码后，直接杀死fpm进程，nginx果然报出了几乎一样的错误；但是实际场景中，没有发现fpm猝死的任何蛛丝马迹，也找不到fpm会在响应头输出之后就猝死的理由；
按照以前的风格，我将通过看源码、调试等方式查个水落石出，现在不想了，先把长连接关掉试试吧；（凭啥直接怀疑长连接？凭直觉）
现在，长连接关了有一周时间了，没有再出现类似错误；还有好多更重要的事情要做，先不纠结这个了；服务器端建立连接的代价也没有大到不可以接受，先这样吧！
这里只讨论rpm方式安装的情况
默认的数据目录为： /var/opt/gitlab 有可能这里空间会比较小，可以在 /etc/gitlab/gitlab.rb 里面修改
gitlab安装 有麻烦的方法： https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md
也有简单的方法： https://about.gitlab.com/downloads/#centos6
yum安装或者脚本安装实在太慢，即使走代理也很慢； 当然，可以:
|
1 |
nohup yum install -y gitlab-ce & |
如果不小心断网又得从来，不可取。
俺的办法是： 用百度的离线下载功能先把rpm： https://packages.gitlab.com/gitlab/gitlab-ce 下载下来，百度离线下载几分钟就能搞定，然后，再从百度下载rpm，再然后：
|
1 |
sudo rpm -i gitlab-ce-8.3.4-ce.0.el6.x86_64.rpm |
安装完成后有提示接下来该怎么做，我建议你接下来不要着急配自己的nginx，而是直接enable rpm中自带的nginx
配置文件基本只有一个： /etc/gitlab/gitlab.rb
修改完直接：
|
1 |
gitlab-ctl reconfigure |
根本不用stop start;
注意：千万不要stop的时候reconfigure，这样总是出错，start状态下直接reconfigure还挺快的
配置见下篇
|
1 |
$ yum install git |
安装依赖：
|
1 |
yum install expat-devel |
|
1 |
yum install zlib-devel perl-ExtUtils-MakeMaker asciidoc xmlto openssl-devel |
获取git源码：
|
1 |
git clone https://github.com/git/git.git |
安装：
|
1 |
cd git |
|
1 |
make |
参考：
http://git-scm.com/download/linux
缘起：
曾经在nginx(1.7.4)两个地方配置过unix socket；一个是nginx日志，一个是fastcgi；但是，这两个地方有所不同。
关于日志的配置，通过unix socket (/dev/log) 写到本地的syslogd，如果syslogd重启了，则/dev/log 其实是被更新了的，但是nginx却不会自动重连，然后nginx就写log失败了。 如此，重启syslogd就得重启nginx，是多么“2”的一件事情啊！
关于fastcgi的配置，通过unix socket访问本地的php-fpm，如果php-fpm重启，则 unix socket不更新，自然影响不到nignx； 如果fpm stop then start，则unix socket会更新，但是，nginx却知道自动重连，也不会影响到nginx。（难道是因为该socket走的是stream的原因？）
注： 如果你不小心将socket文件配到了/tmp 下面，则socket文件可能是660的权限，nginx（用户如果和php-fpm不同）可能就没有权限连接该unix socket
问题： 默认情况下，nginx会自动failover，即： 其中一个上游服务器处理失败时会自动将请求转发到下一个上游服务器；有些情况下是不期望如此的;
但是这里没有区分上游服务器的失败原因，如果是连接失败，则自动fail_over 基本是没问题的；如果是已经发送了数据然后等待响应超时失败，可能并不想fail_over
避免failover的办法：
如果把 proxy_next_upstream 写到fastcgi_pass 中是不会有效果的，虽然不会报错
可能在应用层来避免重复处理才是正道
3,685