分类目录归档：linux

nginx ssl https 设置

1条回复
本文已经过时并且存在大量不安全,请参阅最新文档   https://www.4os.org/index.php/category/https/
nginx 默认编译就是支持https的,只需要开启ssl就好
配置如下:
                listen                  443 ;
                server_name             4os.org *.4os.org;

                ssl                     on;
                ssl_certificate         gz.crt;
                ssl_certificate_key     gz.key;
                ssl_session_timeout     5m;
                ssl_protocols           SSLv2 SSLv3 TLSv1;
                ssl_ciphers             ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
                ssl_prefer_server_ciphers       on;
....

其中:
gz.crt是证书颁发机构给的证书(免费ssl-证书/)
gz.key是解密后的私钥

上文中提到的私钥是加密的,可以在startssl的工具箱里边解密,也可以自己做:

openssl  rsa -in gz.pri -out gz.key,输入私钥生成时设置的密码,出来的就是不加密的私钥了,nginx启动也不会要你输入密码了

补充:

1. “SSL_CTX_use_PrivateKey_file fail”之类的错误,通常都是私钥和证书不匹配造成的,请确认你生成证书与私钥匹配

2.firefox证书需要根证书信息:

wget http://www.startssl.com/certs/sub.class1.server.ca.pem

cat sub.class1.server.ca.pem >> gz.crt

免费SSL 证书

21条回复

不再推荐 startssl,推荐 let’s encrypt, 请参考文章免费HTTPS证书

一般来说,开启https服务总会涉及到证书问题,通常自签发的证书在浏览器会有”鲜红告警”,而CA的证书又颇贵
https://www.startssl.com/ 是一个免费的证书提供商,并支持ie,firefox,chrome等主流浏览器

1.注册,点击右上角的钥匙

选择sign-up,并输入要求填写的所有信息,由于是人工审核,请谨慎填写(必须是私人地址)

2. 注册成功后会收到封邮件(建议留gmail),点击链接会安装一份证书,以后就可以凭证书自动登录该网站了(上图Auth…)

3. 登录后到控制面板,有3个框:分别是工具箱/证书向导/验证向导

先点验证向导(validations wizard),分别验证邮箱和域名(确认该域名属于你,系统一般会发信给域名的postmaster或者你注册域名时留的邮箱)

4. 证书向导,点Certificats wizard,选择web Server SSL证书,下一步

5. 输入私钥的密码,请特别留意密码你清楚记得

6. 然后系统会提示你保存加密私钥(你稍后可以在工具箱里边解密之,不要现在做,请确认保存该密钥),下一步选择域名和子域名申请证书

7. 提交申请,稍等个大概10分钟,会收到邮件提示证书开通,在后台下载就可以了(Toolbox-Retrieve Certificate)

到这里,SSL 证书已经搞定,nginx配置可以参考http://www.4os.org/index.php/2012/05/09/nginx-ssl-https-%E8%AE%BE%E7%BD%AE/

停止和重启:nginx与apache的不同

3条回复

停止和重启apache与nginx有些许不同,彼此经验不能照搬

TERM:

两者相同,都是发指令给父进程,父进程立刻尝试杀死所有的子进程并退出

USR1:

nginx的文档说得很简单:reopen the logfile,实际上的操作是master重新打开日志文件,并改变日志文件权限,是worker进程有读写权限,然后发USR1给worker进程重新打开日志文件,这完全不涉及任何worker进程的重新启动

apache则不同,它的父进程会”建议”所有子进程完成当前请求后退出,父进程将重新读取配置文件和日志文件,每个子进程退出后父进程将生成新的子进程

HUP:

nginx收到这个信号会做3个事情:

1.重新读取配置文件

2.使用新的配置启动新的worker进程

3.旧的worker完成当前请求后退出

apache的做法不同,父进程接收到该信号后会跟TERM信号杀掉所有子进程,重新读取配置文件,重新打开日志文件,并声称新的子进程来服务.与TERM信号不同的是,父进程不退出,服务不会中止

ddos 与 黑洞路由

3条回复

通常遇到ddos或者其他攻击,简单想到的办法是iptable,比如

iptable -A INPUT -s IP -j DROP

实际上,超大规模的攻击使用iptable过滤会非常耗CPU,一般建议使用黑洞路由

从这个网址: http://www.cyberciti.biz/tips/how-do-i-drop-or-block-attackers-ip-with-null-routes.html 可以看到

假设需要屏蔽掉202.33.8.49,有三种不同做法:

1. # route add 202.33.8.49 gw 127.0.0.1 lo

2.#ip route add blackhole 202.33.8.49

3.#route add -host 202.33.8.49 reject

当然,文中没有解释这三种做法的区别与优劣,这里简单说说个人看法

第一种,是把这个ip的路由导向lo 127.0.0.1,其实是相当犯傻的行为,系统会自动的尝试往lo发送数据(tcpdump可见)

第二种,是加入黑洞路由,意思就是直接就丢弃了,当然也不会有对应的应用层程序收到数据包尝试回包了

第三种,先看看man里边怎么说: “reject install a blocking route, which will force a route lookup to fail.  This is for example used to mask out networks before using the default route.  This is NOT for firewalling.”  reject是阻止了”到”这个IP的网络,通常用于在使用默认路由前标识网络,不适用于防火墙,为什么呢?因为应用层程序能收到数据包,只不过尝试回包时会知道网络不可达而已

由此可见,从性能来说使用blackhole是最好的办法

参考:http://en.wikipedia.org/wiki/Null_route

IBM x3650M3 disk fail

发表评论

IBM x3650M3 使用的阵列卡 ServeRAID M10XX and M50XX使用了power save技术
这种不成熟的技术将会导致磁盘wake up的过程中出现不可知的系统故障
比如:

sd 0:2:0:0: timing out command, waited 360s
sd 0:2:0:0: SCSI error: return code = 0x06000000
end_request: I/O error, dev sda, sector 528987842
ext3_abort called.
EXT3-fs error (device sda5) in ext3_dirty_inode: Journal has aborted
__journal_remove_journal_head: freeing b_committed_data
unable to read inode block – inode=898882, block=917148
EXT3-fs error (device sda3) in ext3_dirty_inode: Journal has aborted
EXT3-fs error (device sda3) in ext3_dirty_inode: Journal has aborted
ext3_abort called.
EXT3-fs error (device sda3): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only

使用如下命令检测是否启用了节电模式:
> MegaCLI -AdpGetProp DefaultLdPSPolicy -a0
> Sample Output: “Adapter 0: Default power savings policy : Automatic”
以上输出说明节电模式启用,应当关闭

关闭节电模式:
> MegaCLI -AdpSetProp -DefaultLdPSPolicy -None -a0
or
> MegaCLI -LDSetPowerPolicy None -Lall -aALL
> Sample Output: “Adapter 0: Default power savings policy : None”
以上输出说明节电模式已经关闭

检查热备盘(hot spare)的节电策略:
> MegaCLI -AdpGetProp DsblSpinDownHSP -aALL
> Sample Output: “Adapter 0: Disable spin Down of Hot Spares: Disabled”
以上输出说明热备盘(hot spare)的”禁用了spin down模式禁用设置”,也就是启用的
修改热备盘(hot spare)的节电策略:
> MegaCLI -AdpSetProp -DsblSpinDownHSP -val -aALL

相关链接:http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5087494

HP 修改ILO密码

发表评论

刚一北京同事很无奈的希望俺去机房重置ILO…
于是很无奈的开始找HP机器远程修改密码的办法:
HP的iLO密码可通过hponcfg工具在线修改:

编辑一个文本文件，例如文件名为reset_pw，内容如下:

保存。然后使用hponcfg命令

hponcfg -f reset_pw

这样iLO密码就被重置了。
================================================================
Dell的DRAC密码可通过racadm工具在线修改：

DRAC4默认管理员账号是”root”,该账号处于index的第1位。

DRAC5默认管理员增加了一个”Administrator”，然后才是”root”，root账号处于index的第2位,因此需要注意这里。

PowerEdge系列服务器的DRAC初始密码是”calvin”

DRAC密码恢复，需要先通过root账号登录到操作系统中，然后用racadm命令重置。

注意下边命令中的-i 1那个部分的区别

# DRAC4
# racadm config -g cfgUserAdmin -o cfgUserAdminPassword -i 1 “newpasswordhere”

# DRAC5
# racadm config -g cfgUserAdmin -o cfgUserAdminPassword -i 2 “newpasswordhere”

BCM5709 bnx2.0.2驱动 故障问题

41条回复

RHEL5.5自带的BNX2.0.2跟intel的BCM5709存在兼容性问题

今天有两台发现应用性能监控曲线波动非常厉害,手工测试也发现间中无响应

检查eth1发现rx_fw_discards 数据特别高且在不断增加

# ethtool  -S eth1 | grep rx_fw_discards

rx_fw_discards: 4250136

驱动版本是2.0.2,这个版本在其他节点出现过问题,建议降级到稳定版本或者先增大rx

# ethtool -i eth1

driver: bnx2

version: 2.0.2

刚好有朋友困扰这个问题,放出稳定版驱动和降级办法:

驱动下载: http://www.4os.org/video/other/bnx2.tar.gz

脚本:

cd netxtreme2-5.0.17/bnx2-1.9.20b/src/;

make; make install;

ifconfig eth0 down; ifconfig eth1 down; ifconfig eth2 down;

rmmod bnx2; modprobe bnx2;

service network restart;

请务必使用一个脚本来执行,否则ssh中断又没远程管理就只能重启了

linux访问mssql server

16条回复

使用freetds可以方便的管理微软的SQLSERVER2000 2005
目前的需求是需要监控一台windowns的数据库,非常不稳定
本来想用php+freetds的,后来发现它本身的bin工具就非常强大了,可以直接执行sql语句
加上简单的脚本就可以很好的完成监控任务

关于somaxconn参数

6条回复

我们线上服务器net.core.somaxconn都是默认的128,这个参数会影响到所有AF_INET类型socket的listen队列

Man 2 listen可以知道:

int listen(int s, int backlog);

The  backlog  parameter  defines the maximum length the queue of pending connections may grow to.  If a connection request

arrives with the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying  pro-

tocol supports retransmission, the request may be ignored so that retries succeed.

BUGS

If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN  (128  in  Linux  2.0  &

2.2),  it  is silently truncated to SOMAXCONN.

也就是说,web应用中listen函数的backlog会给我们内核参数的net.core.somaxconn 限制到128,在高突发的请求中可能会导致链接超时或者触发重传

比如nginx 定义NGX_LISTEN_BACKLOG默认到511, 却由于我们参数未曾优化会限制到128,只有128个connections can be queued in kernel listen
queue(by Igor Sysoev).

#define NGX_LISTEN_BACKLOG 511/ls.backlog = NGX_LISTEN_BACKLOG;/ if (listen(s, ls.backlog) == -1) {

相信其他应用比如squid也会有类似问题,突发的大并发connect请求会由于内核listen队列的限制导致链接超时或者重传,从而影响用户体验

以下是实验测试情况,使用2台机器分别以1000个并发,benchmark方式,请求服务器 ( 相当于2000个并发请求同时请求服务器 )

情景1,默认配置, net.core.somaxconn=128,服务器为nginx

测试客户端A:

Transactions:                2072870 hits

Availability:                  99.99 %

Elapsed time:                 179.59 secs

Data transferred:            6096.59 MB

Response time:                  0.08 secs

Transaction rate:           11542.24 trans/sec

Throughput:                    33.95 MB/sec

Concurrency:                  927.34

Successful transactions:     2072871

Failed transactions:             300

Longest transaction:           45.30

Shortest transaction:           0.00

错误率大概是1.5%

测试客户端B:

Transactions:                1859454 hits

Availability:                  99.99 %

Elapsed time:                 179.11 secs

Data transferred:            5468.90 MB

Response time:                  0.09 secs

Transaction rate:           10381.63 trans/sec

Throughput:                    30.53 MB/sec

Concurrency:                  904.45

Successful transactions:     1859454

Failed transactions:             276

Longest transaction:           49.60

Shortest transaction:           0.00

错误率大概也是1.5%

错误提示大都为:

socket: connection timed out

warning: socket: -1803417280 select timed out: Connection timed out

情景2,调整配置, net.core.somaxconn=8192,  nginx显式配置  listen     80 default backlog=8192;

测试客户端A:

** SIEGE 2.69

** Preparing 1000 concurrent users for battle.

The server is now under siege…

Lifting the server siege…      done.

Transactions:                1789818 hits

Availability:                 100.00 %

Elapsed time:                 180.00 secs

Data transferred:            5264.09 MB

Response time:                  0.10 secs

Transaction rate:            9943.43 trans/sec

Throughput:                    29.24 MB/sec

Concurrency:                  997.06

Successful transactions:     1789818

Failed transactions:               0

Longest transaction:            0.87

Shortest transaction:           0.00

错误率是0

测试客户端B:

** SIEGE 2.69

** Preparing 1000 concurrent users for battle.

The server is now under siege…

Lifting the server siege…      done.

Transactions:                1768585 hits

Availability:                 100.00 %

Elapsed time:                 179.31 secs

Data transferred:            5201.65 MB

Response time:                  0.10 secs

Transaction rate:            9863.28 trans/sec

Throughput:                    29.01 MB/sec

Concurrency:                  998.30

Successful transactions:     1768588

Failed transactions:               0

Longest transaction:            3.10

Shortest transaction:           0.03

错误率是0