FPs

Nginx 加載配置的順序分析

問題背景

在部署HTTPS 的時候,2台Nginx 下都部署了多個域名的證書,即NginxA 部署了證書a.com 和b.com 的證書,NginxB 也部署了證書a.com 和b.com ,域名a.com 指向NginxA,域名b.com 指向NginxB。
在用SSL LABS 檢測的時候,發現b.com 會出現“This site works only in browsers with SNI support.”,而a.com 不會。
SNI

SNI 介紹

關於SNI 的簡單介紹:

在 Nginx 中可以通过指定不同的 server_name 来配置多个站点。HTTP/1.1 协议请求头中的 Host 字段可以标识出当前请求属于哪个站点。但是对于 HTTPS 网站来说,要想发送 HTTP 数据,必须等待 SSL 握手完成,而在握手阶段服务端就必须提供网站证书。对于在同一个 IP 部署不同 HTTPS 站点,并且还使用了不同证书的情况下,服务端怎么知道该发送哪个证书?
Server Name Indication,简称为 SNI,是 TLS 的一个扩展,为解决这个问题应运而生。有了 SNI,服务端可以通过 Client Hello 中的 SNI 扩展拿到用户要访问网站的 Server Name,进而发送与之匹配的证书,顺利完成 SSL 握手。

引用來源:关于启用 HTTPS 的一些经验分享(二)

使用OpenSSL 測試NginxA,NginxB,不指定Host 頭,NginxA 返回的是a.com 的證書,NginxB 返回的也是a.com 的證書。

openssl s_client -connect nginx_ip:443 -showcerts < /dev/null 

Nginx 源碼分析

基本確定是配置加載的順序問題。在NginxA 和NginxB 中先加載的都是a.com。 在nginx.conf 中,我用 include 指令 引入了 某目錄下的所有conf 結尾的配置:

include /home/xxxxx/*.conf;

懷疑Nginx include 是按照字典順序,即a-z 的順序。看下源代碼,參考的Nginx 代碼版本是1.11.0。
先找到include 指定相關的函數:
Continue ->


第三屆浪潮廣告大會亂記

Poster

小組組長某天問問是否對浪潮在深圳的壹個會有興趣,看了下會議日程安排,下午的幾個主題好像還有點意思(實際上壹般),那就去吧,順便回廣東吃點好吃的。
Agenda
在北京壹年多,見到各種廠商組織的會議和沙龍,基本都是廣告+水貨分享,然後現場還大都是男的,參加的意義實在不大。

下飛機已經晚上八點多,廠商還派人來接(當甲方真好),到酒店下榻之後,發現希爾頓房間裏的電視居然有不少國外電視臺,WIFI 下部分被墻網站還可以訪問。 Continue ->


監控所有NameServer的SOA 記錄的序列號

使用Bind DLZ或者其他方式搭建了權威DNS,爲了高可用的話,肯定會有多組NameServer。 除了常規的監控外,還需要監控所有SLave 的NS 的SOA 序列號(Serial Number)是否和Master 一致,如果落後的話需要報警,有時候也有可能Master NS生成的記錄有錯,無法同步到Slave NS,也有可能是權限方面出錯等等,總之,這個監控非常有必要。

關於SOA 記錄的介紹可以參考:DNS SOA 记录的结构

@   IN  SOA     nameserver.place.dom.  postmaster.place.dom. (
                           1            ; serial number
                           3600         ; refresh   [1h]
                           600          ; retry     [10m]
                           86400        ; expire    [1d]
                           3600 )       ; min TTL   [1h]

使用dig 命令向特定NameServer 查詢特定域名的SOA 記錄:

> dig @NS_IP domain soa
>>dig @114.114.114.114 google.com soa

> dig @NS_IP domain soa +short #返回簡短的結果
>> dig @8.8.8.8 google soa +short
Continue ->

Haproxy 作爲Shadowsocks 中繼遇到的一個問題

之前用Haproxy 來轉發Shadowsocks 的流量時遇到一個問題,現象是在使用Slack 的時候(聊天使用了Websocket),頻繁重連。憑直覺是由於Haproxy 的某一項timeout 設置的不合理導致的。
Websocket 協議可以分爲2個階段,先用HTTP 握手,然後建立長連接,通過ws 協議進行通信。將Haproxy 作爲中繼時,在建立長連接之後,Haproxy 就轉入tunnel 模式

TUN:tunnel(option http-tunnel):这是 1.0 ~ 1.5-dev21 的默认模式,类似于隧道,HAProxy 仅处理第一个请求和响应,剩余的报文将直接转发而不进行处理。尽量不要使用这个模式,因为它在日志记录和 HTTP 处理上有很多问题。 --來源:liaoph.com

涉及到的timeout 見下圖:
timeout_websocket
圖片來源:www.yuangguo.info

我們遇到的需要頻繁重連的情況,其實是由於timeout tunnel 設置不合理導致的。官方給的關於timeout tunnel 的解釋:

Set the maximum inactivity time on the client and server side for tunnels.

The tunnel timeout applies when a bidirectional connection is established between a client and a server, and the connection remains inactive in both directions. This timeout supersedes both the client and server timeouts once the connection becomes a tunnel. In TCP, this timeout is used as soon as no analyser remains attached to either connection (eg: tcp content rules are accepted). In HTTP, this timeout is used when a connection is upgraded (eg: when switching to the WebSocket protocol, or forwarding a CONNECT request to a proxy), or after the first response when no keepalive/close option is specified......

另外官方給出了一個配置示例:

defaults http
    option http-server-close
    timeout connect 5s
    timeout client 30s
    timeout client-fin 30s
    timeout server 30s
    timeout tunnel  1h    # timeout to use with WebSocket and CONNECT

把中繼的Haproxy 的這項值設爲1h,解決了Slack 會頻繁重連的問題。

參考鏈接:


阿里漏洞一枚-订单信息

  • 漏洞名称:地区订单信息用户信息可泄漏
  • 提交时间: 2016-05-21 13:37:17
  • 漏洞类型:业务安全/运营风险 - 设计缺陷/逻辑错误
  • 危害等级:高
  • 贡献值:70
  • 安全币:273
  • 当前状态: 修复中

漏洞详情:

一、详细说明:其中包括场景、截图、漏洞重现的方法,支付宝相关漏洞,请填写支付宝帐号
淘宝天猫订单评价中已经对用户信息做了隐藏,但是只是隐藏了中间部分,昵称的首字母和末字母依旧可见,如下图:
Continue ->


React 從入門到做個實時搜索框

之前給內網做的DNS 平臺的查詢接口是通過API 的方式,想着不如擼一個搜索框給大家用,順便也看看React。 先按照阮一峯的React 入門實例教程 過了一遍,有個大概的瞭解之後,以文中第十一個例子爲模板,照貓畫虎。

原來的平臺是用Flask+Jinja2 寫的,所以先引入一些react 的資源,都是手動加的,還沒看前端那一堆包管理的工具,用了browser.js 做轉換,先不考慮效率。這裏在版本上遇到幾個坑,react.js 和browser.js 似乎有依賴性問題。

{% block head %}
{{super()}}
<script src="{{ url_for('static',filename="react.min.js") }} "></script>
<script src="{{ url_for('static',filename="react-dom.min.js") }} "></script>
<script src="{{ url_for('static',filename="react-with-addons.min.js") }} "></script>
<script src="{{ url_for('static',filename="browser.min.js") }} "></script>
{% endblock %}

服務端的搜索API:

http://abc.com/search?keyword=

希望達到的效果是用戶輸入查詢關鍵詞之後,通過AJAX 請求實時的在頁面上顯示結果。

源碼:

Continue ->

ElasticSearch 用於日誌記錄

EdgeofSanity

  • 原文地址
    • http://edgeofsanity.net/article/2012/12/26/elasticsearch-for-logging.html
  • 已獲得原文作者翻譯許可,本文遵循原文許可協議。
  • 原文發表時間:2012-12-26

在我工作中,我們在Web 前端搜索上使用ElasticSearch。性能至關重要,對我們而言,大多數的數據是靜態的。
我們每天更新搜索索引,不過用舊的索引跑幾個星期也沒問題。這個集羣大部分的流量是搜索;這是一個“重讀”的集羣。一開始的時候我們有一些性能上的小問題,
不過我們通過和ElasticSearch 的Shay Bannon 密切合作解決了這些問題。現在我們的前端集羣非常可靠,靈活,和快速。

我目前的工作是部署一個符合規範,同時也非常有用的中心化的日誌基礎服務。這個日誌基礎服務的目標是儘可能的實現Splunk 的功能。我之前寫的一篇關於日誌記錄的文章解釋了我們爲什麼決定不用Splunk

評估了一些選擇之後,我決定使用ElasticSearch 作爲這個系統的後端存儲。這個集羣的類型和我們之前部署的用於大量搜索的集羣非常不同

譯文
EveryCloud 貢獻的一篇俄語譯文

索引設計

兩個流行的開源日誌分發系統是Graylog2LogStash。在寫這篇文章的時候,穩定版本的Graylog2 只支持從單一的索引讀/寫。正如送之前文章中指出的,Graylog2 存在很多嚴重的問題。0.10.0 版的Graylog2 將包含聯合多個索引的能力。然而,我已經在LogStash 的索引上有了一些經驗,因爲之前它是唯一的選擇。

爲了儘可能得充分利用ElasticSearch 用來做日誌記錄,你需要使用多個索引。當你滾動更新索引的時候有非常多種方式,不過LogStash 默認的每天滾動更新的方式是最合理的。這樣,你會看到下列內容:

  • logstash-2012.12.19
  • logstash-2012.12.20
  • logstash-2012.12.21
  • logstash-THE_WORLD_HAS_ENDED

你可以跟蹤每個索引中有多少個文本。在百萬或者千萬個文本之後滾動更新,或者其他你隨意設定的數值之後,但是這樣你會給你自己以後帶來更多的工作內容。在某些少見的情況下其他的索引方式可能會更高效,但是對於大多數用戶來說,一天一個索引是最簡單的,也能最有效的利用你的資源。

Continue ->

找出共同喜好最多的豆友

之前有一個想法,遍歷豆瓣的用戶,找出共同喜好最多的朋友,由於豆瓣的反爬蟲挺粗暴的,一直沒想好怎麼做,如果遍歷ID,估計豆瓣埋了不少雷。

1:
抓下友鄰列表:接口:https://www.douban.com/contacts/rlist?start=,過濾得到ID列表。

1
2
3
4
5
6
7
8
#!/usr/bin/env bash
list=""

for i in `seq 0 20 200`;do
  curl -s 'https://www.douban.com/contacts/rlist?start='"${i}" -H ... \
  | grep '<li id="u' | grep -oE '[0-9]+' >> ${list}
  sleep 3
done

2:
用第1步中的用戶名ID列表,訪問主頁,得到共同喜好數,排序,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
#!/usr/bin/env bash
list=""
out=""

for i in `cat ${list}`; do
  num=`curl -s 'https://www.douban.com/people/'"${i}/" -H ... |grep -Eo "共同的喜好\([0-9]+\)" |grep -Eo '[0-9]+' || echo "0"`
  echo $num "  " $i >> ${out}
  sleep 3
done

cat ${out} | sort -rn

得到下列結果:
Continue ->


記一個退出終端進程不退出的問題

某一天開發同學問了一個問題,他們在線上跑一個job,沒用screen,nohup,把iTerm 窗口關了,job 沒掛。再登錄進去看,PPID 變成1,即進程被init 進程接管。
在對應機器上執行shopt, 發現:

...
gnu_errfmt      off
histappend      off
histreedit      off
histverify      off
hostcomplete    on
huponexit       off
interactive_comments    on
lastpipe        off
lithist         off
login_shell     on
mailwarn        off
...

注意CentOS 7 默認將huponexit 設爲off 了,这样在用户将Shell 退出结束会话时,系统不会發送 SIGHUP 給所有進程,這效果其實類似使用了nohup,nohup 的作用就是忽略HUP 信號。

huponexit
  If set, bash will send SIGHUP to all jobs when an interactive login shell exits.