使用 MegaCli 遇到的两个问题

总结一下使用 MegaCli 遇到的问题。

 

系统中有 3T 11 块硬盘,fdisk -l 看不到盘,此时可以使用:

MegaCli -PDMakeJBOD -PhysDrv[32:1,32:2,32:3,32:4,32:5,32:6,32:7,32:8,32:9,32:10,32:11] -a0

解决此问题。
执行上面的命令之后,如果想对其中若干块盘做 RAID,会报错,比如:

# MegaCli -CfgSpanAdd -R10 -Array0[32:1,32:2] -Array1[32:3,32:4] -Array2[32:5,32:6] -Array3[32:7,32:8] -Array4[32:9,32:10] WB Direct -a0

The specified physical disk does not have the appropriate attributes to complete
the requested command.

Exit Code: 0x26

此时,把硬盘的 NonRaid 关掉就 OK 了,命令:

MegaCli -AdpSetProp -EnableNonRaid -0 -a0

搭建 sniproxy

sniproxy 源码在 https://github.com/dlundquist/sniproxy,它的作用是:

Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session.

 

安装:

rpm -ivh http://mirror.zhoufengjie.cn/centos/el6/x86_64/RPMS/tyumenmirror-1.0-1.el6.noarch.rpm

yum -y install sniproxy

如果使用源码编译,最要把 udns 编译进去,否则如果配置 .* *:443 类似规则的时候会报:Only socket address backends are permitted when compiled without libudns

 

修改配置文件 /usr/local/sniproxy/etc/sniproxy.conf:

user daemon
pidfile /var/run/sniproxy.pid

error_log {
  syslog daemon
  priority notice
}

listen 443 {
  protocol tls
  table https_hosts

  access_log {
    filename /var/log/sniproxy.log
  }
}

table https_hosts {
  .* *:443
}

listen 80 {
  protocol http
  table http_hosts

  access_log {
    filename /var/log/sniproxy.log
  }
}

table http_hosts {
  .* *:80
}

table {
  .* 127.0.0.1
}

启动:

/usr/local/sniproxy/sbin/sniproxy -c /usr/local/sniproxy/etc/sniproxy.conf

 

然后修改 /etc/hosts 测试:

52.221.229.x play.google.com
52.221.229.x www.baidu.com

# curl -I “https://play.google.com/store/apps/details?hl=en&id=tr.com.fugo.kelimeavi2.en”
HTTP/1.1 200 OK

# curl -I http://www.baidu.com
HTTP/1.1 200 OK

都是 OK 的。

 

修改 hosts 很麻烦,可以使用  dnsmasq 来管理你的解析,在 dnsmasq 上把你需要的域名修改成你的 sniproxy,配合 dnscrypt,防止 DNS 被污染。详情请看:

https://www.logcg.com/archives/981.html

https://gist.github.com/tawateer/fff8798407693d74b80d44e46806cc82

 

python requests 信任自签名证书

我在一台 Nginx 上搭建 https 服务,证书使用自签名的证书,然后使用 Python 访问 https 服务。

 

解决方法1:

#!/bin/env python

import requests

url = "https://52.77.252.184/test.txt"

ret = requests.get(url, verify="/tmp/ssl/requests_test.crt")
print ret.status_code

通过 verify 指定证书,表示相信此证书(requests_test.crt 是服务器端证书);也可以用 verify=False,表示不验证服务器端的证书。

 

解决方法2:

设置环境变量 REQUESTS_CA_BUNDLE:
export REQUESTS_CA_BUNDLE=/tmp/ssl/requests_test.crt

然后使用 request 访问。

#!/bin/env python

import requests

url = "https://52.77.252.184/test.txt"

ret = requests.get(url)
print ret.status_code

搭建邮箱服务器遇到的发送邮件的问题

我在机房搭建了几台 Postfix,代理机房机器给公司邮箱发邮件( 公司使用 Gmail ),默认邮件会被谷歌拒收,这里需要注意一下。

 

1. SPF。

Sender Policy Framework (SPF) records allow domain owners to publish a list of IP addresses or subnets that are authorized to send email on their behalf.  The goal is to reduce the amount of spam and fraud by making it much harder for malicious senders to disguise their identity.  To learn more, visit the SPF Website.

SPF 的规则是:

接收方会验证发送方的公网 IP,如果接收方域名的 SPF 记录中包含这个 IP,认为是正确的邮件,否则认为是伪造的。

举个例子: 13_F7_9T$T}WM61VQTE`O[GD

2JN23o423osrwerwe

23G234o23u4nsdf

v=spf1 表示是第一版的 SPF;

include 表示包含这个域名的 SPF;

~all 表示如果都不匹配,SoftFail,如果 -all,表示都不匹配直接 Fail,如果 +all,表示通过,SPF 规则就无用了,如果 ?all 表示 Neutral,中立,你自己看着办。

此外,还有几个机制:

mx,表示如果发送方 IP 在此域名的 mx 记录解析结果里,通过;

a,比如 a:mx1.nosa.me a:mx2.nosa.me,如果发送方 IP 在 a 指定的域名解析结果中,那么通过;

ptr,比如 ptr:otherdomain1.com ptr:otherdomain2.com,官方解释:The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches。官方建议关闭,因为会带来大量的解析查询。

 

更多的机制看这里:

http://www.openspf.org/SPF_Record_Syntax

http://www.spfwizard.net/  这个网站可以生成 SPF ( TXT ) 记录。

 

2. DKIM。

DomainKeys Identified Mail (DKIM)  对邮件进行签名,防止内容被篡改。

在 Centos 下可以使用 dkim-milter 这个包(或者 opendkim ),比如:

EBDB8091-78E0-4522-B54F-97883FBDDDC4

通过在 dkim-filter.conf 配置使用 mx 这两个文件,mx.private 是私钥,mx.txt 则是包含公钥,看下 mx.txt 的内容:

mx._domainkey IN TXT “v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2dzV0IjYa76/Wc0WLMFhv4eCeZZX1mudLzQ003siBr1XG1oCnrPRClPchpPYigdODj/hyAP5tqHpaV8yskjgHByAL4WzsqxV6N8JPyrxejLfR+TN/Q3FTDvyLJZgsr6JuaHPO2hCT6ymNk/TbAX3VbDjJltLkc3GI/gcKWtm1TQIDAQAB” ; —– DKIM mx for nosa.me

此时解析一下 mx._domainkey.nosa.me TXT,可以看到:

99D80393B

 

DDNS 报错:RRset exists (value dependent)’ prerequisite not satisfied

问题场景:

我们的装机系统使用 DHCP + DNS 环境来保存 SN 和 控制卡 IP 的映射关系,很久之前开始发现控制卡因为损坏更换之后,使用 idrac-SN 解析出来的 IP 是老的,连不上,而 控制卡已经通过 DHCP 获得了新的 IP ( 通过 /var/lib/dhcpd/dhcpd.leases 查看 )。

 

看 DNS 的日志 /var/named/data/named.run 有类似如下报错:

21-Jul-2015 16:13:37.002 client 10.2.1.1#19205: updating zone ‘ilo.xxx.com/IN’: update unsuccessful: idrac-1K39D02.ilo.xxx.com: ‘name not in use’ prerequisite not satisfied (YXDOMAIN)
21-Jul-2015 16:13:37.003 client 10.2.1.1#44065: updating zone ‘ilo.xxx.com/IN’: update unsuccessful: idrac-1K39D02.ilo.xxx.com/TXT: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)

看起来是 DHCPD 更新 DNS 失败,显示 TXT 已经存在,条件不满足。

TXT 在这里是 mac 和 控制卡 hostname 等的哈希,更换控制卡之后 TXT 发生变化,和 DNS 中的 TXT 不一致,所以更新不了。

然后我做了两个尝试:
1. 把 DNS 中的 TXT/A/PTR 记录删掉,重启控制卡重新获取 IP,发现 DNS 此时可以正确加上;
2. 只把 TXT 记录删掉,同样重启控制卡重新获取 IP,不会添加 DNS。

 

手动删除 TXT/A/PTR 记录太麻烦了,最好的方法是在 DHCP 中加一个选项:

update-conflict-detection false

如果 TXT 不存在或者不匹配,都会重写 TXT/A/PTR 到 DNS,是完全 OK 的,已验证。

 

http://comments.gmane.org/gmane.network.dhcp.isc.dhcp-client/6202

https://lists.isc.org/pipermail/dhcp-users/2013-January/016367.html

https://lists.isc.org/pipermail/dhcp-users/2013-January/016378.html