nginx服务器ssl加密传输配置 (转)

上次我们收到了Comodo发过来的认证证书,接着介绍怎么在nginx服务器下进行配置。首先进入到nginx的conf目录中,找到你需要修改的conf文件,在里面加入ssl服务配置项。内容为:

server  {    listen       443; # ssl默认是监听443端口

    server_name  www.yourdomain.com yourdomain.com;

    index index.html index.htm index.php;

    root  /你的网站根目录;

    # SSL

    ssl on;

    ssl_certificate  /usr/local/webserver/nginx/ssl/certs/yourserver.crt;

    ssl_certificate_key  /usr/local/webserver/nginx/ssl/certs/yourserver.key;

 

    ssl_session_timeout  5m;

#        ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_protocols  SSLv3 TLSv1;
    ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   on;

     #… 省略后面的相关配置,和你的80端口配置一致 

}

上面可以看到首先我们启用443端口来提供https服务,后面#SSL段则配置了服务器启用ssl on,ssl_certificate我们指定了使用的证书文件myserver.crt,ssl_certificate_key则配置了这个证书所对应的私钥。你需要做的就是将上面生成csr文件时对应的私钥和你收到的证书文件复制到指定的位置即可,具体位置你可以自行指定。

接下来启动nginx,试着用浏览器访问一下你的https主页,你会发现你的主页不能显示,浏览器会出现一个安全警告,原因是这里我们漏掉了一步,没有将Comodo发给我们的根认证证书附加到我们的证书的后面。具体做法是从comodo发给我们的附件里面找到PositiveSSLCA.crt,把它添加到我们自己证书的后面,

cat PositiveSSLCA.crt >> yourserver.crt

这样再次重启nginx,浏览器就显示正常了。 解释一下问什么我们要把PositiveSSLCA.crt附加到我们证书的后面才有效,原因是证书是以链的形式颁发的,具有根证书颁发权利的机构很少,他们颁发的证书已经被各大厂商所认可,你的浏览器里面默认就已经安装了一些根证书,由这些根证书颁发机构来认证多个中间商,中间商会提供认证服务给不同厂商和个人。而我们得到的证书就是位于一个证书链的最末端,我们的证书浏览器是不能识别的,需要链证书来对我们证书签名才行,当然链证书还需要根证书的认证才能有效。在nginx的配置中,只需要把链证书附加到我们证书的后面就行。最终我们的证书看起来像这个样子:

最后有的朋友可能在生成csr和私钥的时候输入了密码,结果nginx每次启动的时候,都会要求你输入密码才能够启动,这样机器重启等需要nginx自启动的时候就有问题。不过不用担心我们可以使用命令来重新生成一个不需要密码的私钥,替换你原来的那个就可以了。具体做法为:

openssl rsa -in myserver.key -out myserver.key.nopasswd

用不带密码的那个key替换下,重启nginx,不会再要密码了。

【转】使用rpm命令时没有任何响应, 如何解决?

平台: RHEL5.4

如执行rpm -q 等命令就一直hang在那里不动, ps看一下发现n多的rpmq进程挂住了.

# ps -ef | grep rpmq     

root      1202  1199  0 Aug31 ?        00:00:00 /usr/lib/rpm/rpmq -q –all –qf %{name}-%{version}-%{release}.%{arch}.rpmn
root      1519  1517  0 10:52 pts/2    00:00:00 /usr/lib/rpm/rpmq -q –all –qf %{name}-%{version}-%{release}.%{arch}.rpmn
root      1623  1620  0 Aug22 ?        00:00:00 /usr/lib/rpm/rpmq -q –all –qf %{name}-%{version}-%{release}.%{arch}.rpmn

这些进程是每晚crontab执行/etc/cron.daily/rpm后, 更新本机rpm库到 /var/lib/rpm/__db.* 文件里. 可能曾经 /var 目录磁盘满过, 所以才出现这样情况, 现在要做的如下:

# rm -f /var/lib/rpm/__db.*

然后再执行rpm命令就没有问题了. 最好再重建一下rpm库

# rpm -vv –rebuilddb
# /etc/cron.daily/rpm

refer: http://www.linuxquestions.org/questions/red-hat-31/rpm*-hangs-107312/

–End–

%iowait并不能反应磁盘瓶颈 (转)

%iowait并不能反应磁盘瓶颈

iowait实际测量的是cpu时间:
%iowait = (cpu idle time)/(all cpu time)

这个文章说明:高速cpu会造成很高的iowait值,但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法,就是很高的read/write时间,一般来说超过20ms,就代表了不太正常的磁盘性能。为什么是20ms呢?一般来说,一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于,现代硬盘数据传输就是几微秒或者几十微秒的事情,远远小于寻道时间2~20ms和旋转延迟4~8ms,所以只计算这两个时间就差不多了,也就是15~20ms。只要大于20ms,就必须考虑是否交给磁盘读写的次数太多,导致磁盘性能降低了。

作者的文章以AIX系统为例,使用其工具filemon来检测磁盘每次读写平均耗时。在Linux下,可以通过iostat命令还查看磁盘性能。其中的svctm一项,反应了磁盘的负载情况,如果该项大于15ms,并且util%接近100%,那就说明,磁盘现在是整个系统性能的瓶颈了。

来自:http://blog.morebits.org/?p=125

 

iostat来对linux硬盘IO性能进行了解

转载自:扶凯: http://www.php-oa.com/2009/02/03/iostat.html
以前一直不太会用这个参数。现在认真研究了一下iostat,因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器

$iostat -x 1
Linux 2.6.33-fukai (fukai-laptop)          _i686_    (2 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
5.47    0.50    8.96   48.26    0.00   36.82

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               6.00   273.00   99.00    7.00  2240.00  2240.00    42.26     1.12   10.57   7.96  84.40
sdb               0.00     4.00    0.00  350.00     0.00  2068.00     5.91     0.55    1.58   0.54  18.80

rrqm/s:      每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s:        每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s:        每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s:        每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s:        每秒读扇区数。即 delta(rsect)/s
wsec/s:        每秒写扇区数。即 delta(wsect)/s
rkB/s:        每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。(需要计算)
wkB/s:        每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz:    平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:    平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await:        平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm:        平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:        一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait。
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 IO 也会很小.如果数据拿的大,才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的。

另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。

别人一个不错的例子(I/O 系统 vs. 超市排队)

举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连 钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能 5 分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。

我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间。

下面是别人写的这个参数输出的分析

# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个 I/O 请求却需要等上 78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约 29 个),平均队列却不长 (只有 2 个 左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的。

一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有 bug,avgqu-sz 值应为 2.23,而不是 22.35。

 

innodb插件方式安装myql 5.1

yum install gcc gcc-c++

groupadd mysql
useradd –shell /sbin/nologin -g mysql mysql
tar zxvf mysql-5.1.58.tar.gz
cd mysql-5.1.58

 

#设置一下 CFLAGS 和 CXXFLAGS,尤其要注意打开 HAVE_DLOPEN 选项
CFLAGS=’-O2 -DHAVE_DLOPEN -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’

CXXFLAGS=’-O2 -DHAVE_DLOPEN -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’

./configure –prefix=/data1/app/services/mysql
–with-charset=utf8
–with-collation=utf8_general_ci
–with-extra-charsets=complex
–enable-thread-safe-client
–enable-local-infile
–enable-assembler
–with-big-tables
–localstatedir=/data1/app/services/mysql/data
–with-unix-socket-path=/data1/app/tmp/mysql.sock
–with-mysqld-user=mysql
–with-plugins=max-no-ndb

make
make install

cp support-files/my-medium.cnf /etc/my.cnf
cp support-files/mysql.server /etc/init.d/mysql
chmod u+x /etc/init.d/mysql

cd /data1/app/services/mysql
bin/mysql_install_db –user=mysql –force –datadir=data
chown -R root  .
chown -R mysql data
chgrp -R mysql .

chkconfig –add mysql
chkconfig –level 345 mysql on
bin/mysqld_safe –user=mysql &
service mysql restart

 

ln -s /data1/app/mysql52/bin/mysql /sbin/mysql
ln -s /data1/app/mysql52/mysqladmin /sbin/mysqladmin

 

my.cnf文件参考(注意红色部分):

[mysqld]
datadir=/data1/app/services/mysql/data
socket=/data1/app/tmp/mysql.sock
pid-file=/data1/app/tmp/mysql.pid
user=mysql
port=3308

ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).

old_passwords=1

character-set-server = utf8
collation-server = utf8_general_ci
default-storage-engine=INNODB

skip-name-resolve
skip-external-locking
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 32512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 8M
thread_cache_size = 32
query_cache_size = 8M
tmp_table_size = 64M

# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 16
lower_case_table_names = 1
max_connections = 100

slow_query_log_file = /data1/app/log/mysql-slow.log
slow_query_log = 1
log-queries-not-using-indexes
long_query_time = 1
wait_timeout = 86400

log-bin = mysql-bin
server-id = 1
expire-logs-days = 7

innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 16M
innodb_file_per_table
innodb_open_files = 65535
innodb_lock_wait_timeout = 50
innodb_log_file_size = 512M
innodb_log_buffer_size = 16M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2

binlog_format = mixed
transaction-isolation = READ-UNCOMMITTED

[mysqld_safe]
log-error=/data1/app/log/mysql.log

 

启动数据库进去看下:

[root@fbtw-topcity log]# mysql -h 127.0.0.1 -P 3308
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 2
Server version: 5.1.58-log Source distribution

Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the buffer.

mysql> show plugin;         
+————+———-+—————-+———————+———+
| Name       | Status   | Type           | Library             | License |
+————+———-+—————-+———————+———+
| binlog     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| partition  | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| ARCHIVE    | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| BLACKHOLE  | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| CSV        | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| FEDERATED  | DISABLED | STORAGE ENGINE | NULL                | GPL     |
| MEMORY     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| MyISAM     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| MRG_MYISAM | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| InnoDB     | ACTIVE   | STORAGE ENGINE | ha_innodb_plugin.so | GPL     |
+————+———-+—————-+———————+———+
10 rows in set, 1 warning (0.00 sec)

mysql> show variables like ‘innodb_%’;
+———————————+————————+
| Variable_name                   | Value                  |
+———————————+————————+
| innodb_adaptive_flushing        | ON                     |
| innodb_adaptive_hash_index      | ON                     |
| innodb_additional_mem_pool_size | 16777216               |
| innodb_autoextend_increment     | 8                      |
| innodb_autoinc_lock_mode        | 1                      |
| innodb_buffer_pool_size         | 268435456              |
| innodb_change_buffering         | inserts                |
| innodb_checksums                | ON                     |
| innodb_commit_concurrency       | 0                      |
| innodb_concurrency_tickets      | 500                    |
| innodb_data_file_path           | ibdata1:10M:autoextend |
| innodb_data_home_dir            |                        |
| innodb_doublewrite              | ON                     |
| innodb_fast_shutdown            | 1                      |
| innodb_file_format              | Antelope               |
| innodb_file_format_check        | Antelope               |
| innodb_file_per_table           | ON                     |
| innodb_flush_log_at_trx_commit  | 2                      |
| innodb_flush_method             | O_DIRECT               |
| innodb_force_recovery           | 0                      |
| innodb_io_capacity              | 200                    |
| innodb_lock_wait_timeout        | 50                     |
| innodb_locks_unsafe_for_binlog  | OFF                    |
| innodb_log_buffer_size          | 16777216               |
| innodb_log_file_size            | 536870912              |
| innodb_log_files_in_group       | 2                      |
| innodb_log_group_home_dir       | ./                     |
| innodb_max_dirty_pages_pct      | 75                     |
| innodb_max_purge_lag            | 0                      |
| innodb_mirrored_log_groups      | 1                      |
| innodb_old_blocks_pct           | 37                     |
| innodb_old_blocks_time          | 0                      |
| innodb_open_files               | 65535                  |
| innodb_read_ahead_threshold     | 56                     |
| innodb_read_io_threads          | 4                      |
| innodb_replication_delay        | 0                      |
| innodb_rollback_on_timeout      | OFF                    |
| innodb_spin_wait_delay          | 6                      |
| innodb_stats_method             | nulls_equal            |
| innodb_stats_on_metadata        | ON                     |
| innodb_stats_sample_pages       | 8                      |
| innodb_strict_mode              | OFF                    |
| innodb_support_xa               | ON                     |
| innodb_sync_spin_loops          | 30                     |
| innodb_table_locks              | ON                     |
| innodb_thread_concurrency       | 0                      |
| innodb_thread_sleep_delay       | 10000                  |
| innodb_use_sys_malloc           | ON                     |
| innodb_version                  | 1.0.17                 |
| innodb_write_io_threads         | 4                      |
+———————————+————————+
50 rows in set (0.02 sec)

mysql>

openvpn 加路由失败的问题

openvpn在win7或windows 2003有时会有下面的问题:

Thu Apr 07 23:13:51 2011 Notified TAP-Win32 driver to set aDHCP IP/netmask of 192.168.0.4/255.255.255.0 on interface{8FE77B49-DAF1-492B-881F-B15C991EF754} [DHCP-serv: 192.168.0.0,lease-time: 31536000]

Thu Apr 07 23:13:51 2011 NOTE: FlushIpNetTable failed oninterface [15] {8FE77B49-DAF1-492B-881F-B15C991EF754} (status=5) :拒绝访问。  Thu Apr 07 23:13:52 2011 TEST ROUTES: 1/1 succeeded len=1ret=1 a=0 u/d=upThu Apr 07 23:13:52 2011 route ADD 192.168.1.0 MASK255.255.255.0 192.168.0.1Thu Apr 07 23:30:54 2011ROUTE: route addition failed usingCreateIpForwardEntry: 至少有一个参数不正确。  [if_index=15]Thu Apr 07 23:30:54 2011 Route addition via IPAPI failedThu Apr 07 23:30:54 2011 Initialization SequenceCompleted

 

关于

NOTE: FlushIpNetTable failed oninterface [15] {8FE77B49-DAF1-492B-881F-B15C991EF754} (status=5) :拒绝访问。 

的问题,一般在windows 2003上出现比较多,可能是启动了windows 2003的路由及远程访问服务,停止这个服务后应该可以解决。

 

关于

ROUTE: route addition failed usingCreateIpForwardEntry: 至少有一个参数不正确。

的问题,可以在配置文件内加下面三个参数解决:

script-security 3
route-method exe
route-delay 2

 

另外win7的系统需注意要用管理员权限运行openvpn,否则会因没有权限加路由而失败。