最近有同学找到我,说是libc的一个链接被误删了.在libc的一些链接被删除后,ssh就不能登陆了,因为基本所有的动态链接的程序都是需要使用libc pm@debian:/ $ ldd /usr/sbin/sshd |grep libc.solibc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fca3ea2e000) 另外重启也是不能登陆系统的,因为/sbin/init也是需要使用libc.so…. pm@debian:/ $ ldd /sbin/init|grep libc.solibc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faee32df000) 解决的办法只有单独有livecd或者有条件PXE进系统去把分区挂载起来,然后单独把链接恢复.

这两年ospf这个内部网关协议在互联网公司的链路负载均衡上出现的频率越来越高，BAT公司都是用OSPF+LVS做负载均衡。连小米这样的公司也开始这样玩了。ospf的配置实际是比较简单的，主要是一般就网工比较了解这个，其他部门的人都这些都没有任何概念，觉得很生疏。简单贴2个配置文件。 quagga实际是个套件，里面有zebra，ospfd，ripd，bgpd等等。其中zebra是ip路由管理进程，可以去更新kernel的路由、更新本地接口的地址或者在把一个的路由协议的路由表重分发到其他重分发到其他的路由协议，比如把ospfd里的发到bgpd里去。ospfd、ripd、bgpd是各自负责ospd，rip，bgp协议的守候进程。所以一般我们在本地服务器上配置ospf会涉及2个配置文件，一个是zebra的zebra.conf，另外一个是ospfd的ospfd.conf。服务器的上联模式可以选择单上联或者双上联，具体的细节配置需要根据实际的硬件条件（主要是看上联交换机，千兆上联的交换机一般比较屌丝，LSA的支持可能也不够完善，最好使用单上联的模式）；默认路由可以本地配置死，也可以就默认通过ospfd从上联交换机学习默认路由，我一般比较推荐千兆上联直接配死。 架设服务器有4个网卡，eth0,eth1做bond连本地的内网接入交换机，eth2单上联到专门配置ospf的交换机。eth2和上联交换机的互联IP是：192.168.20.100/30这个网段，本地使用192.168.20.102这个互联地址，交换机上配置192.168.20.101.本地可以宣告的地址是192.168.200.0/24内的任意地址。 zebra.conf hostname "XXXX" password xxxx enable password xxxxx log file /var/log/zebra.log log syslog interface lo interface bond0 link-detect interface eth2 link-detect #配置link-detect的好处是链路短掉后上层交换机马上能感知，否则只能等ospf的hello超时才会把这个链路标记为不可用。可以缩短链路故障后的影响时间 interface eth3 ospfd.conf hostname XXXX password xxxx enable password xxxx log file /var/log/ospf.log interface bond0 interface eth3 interface eth2 ip ospf network point-to-point ip ospf message-digest-key 1 md5 PASSWORDXXX ip ospf hello-interval 1 ip ospf dead-interval 3 interface lo router ospf ospf router-id YOU_LOCAL_IP network 192.168.20.102/30 area 0.0.0.102 network 192.168.200.0/24 area 0.0.0.102 area 0.0.0.102 authentication message-digest line vty ospfd.conf里需要在interface里配置好网络类型，验证的密码，hello-interval和dead-interval时间。router ospf里需要把互联地址的网段配在network里，也要把想宣告的网段配置在里面。ospfd会把在这个网段内的接口分配后面指定的area里。 ...

一般我们在服务涉及多个网段的时候是直接配置一下策略路由，达到哪个口进哪个口出的目的。最近手上又批机器，因为各种原因。机器上2个网卡各上联到不通的交换机，每个网卡配置的IP也是不同的。考虑到单个交换机挂掉的情况，我就直接配置了2个默认的网关，设置不同的优先级。配置相对简单，单个交换机挂掉的时候还能工作。 #cat route-eth0 default via 10.20.25.1 metric 1 [root@test /etc/sysconfig/network-scripts] #cat route-eth1 default via 10.20.25.12 metric 2 [root@test/etc/sysconfig/network-scripts] # 另外需要注意设置一下rp_filter允许从1个网卡进来的包走另外一个网卡出去。 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0

今天有同学不小心在/etc/profile.d/下的一个脚本里加了一个exit。然后就杯具了，无论如何都登录不进去，试过了ssh，rsync，sftp都不行。 /etc/profile.d/下的配置文件会在/etc/profile生效的时候顺便被执行了一遍，其实bash是可以指定不读取配置文件，直接进去把对应的文件有sed修改好就行了。 sudo ssh -t 192.168.1.6 “bash –noprofile ;sed -i ’s/exit//’ /etc/profile.d/xxx.sh "

无论是权威还是递归DNS，防攻击都是特别需要的。但是现在一般开源的bind在这方面又总是有些欠缺。最近一段时间一直在查看相关的文档。 对于普通的ISP的递归DNS，一方面只允许自己的客户IP段来递归，另外可以配合使用rrl限流模块。rrl限流模块在有大量请求的时候还是可以起到不少作用的。只是这个限流的值需要把握好。 对于自己单独搞的递归DNS。类似114的这种，一般使用anycast模式，多个机房间用BGP进行流量分配，硬抗的能力能提升不少;另外就是做流量清洗，可以学习到每个IP段正常的DNS请求进入时候的TTL值，一般的DNS伪造的攻击很难试出这个正常的TTL值。 最简单的模式，也可以抓包做流量分析，直接把疑似黑名单封了。

线上经常因为系统盘的故障或者是SAS卡驱动的问题使得/或者/home掉了，那么ssh信任登录的时候就会因为找不到AuthorizedKeysFile里面指定的文件而造成无法登录服务器。解决的思路就是可以设置多个authorized_keys,比如放一份到内存里面（可能会存在一些安全问题，不过内部系统应该可控）。openssh到5.8版本以上，可以AuthorizedKeysFile后面支持多个路径，之前的版本比如centos 5(OpenSSH_4.3p2)的可以设置AuthorizedKeysFile2。 sshd_config设置AuthorizedKeysFile %h/.ssh/authorized_keys /sshkeys/.ssh/authorized_keys或者AuthorizedKeysFile2 /sshkeys/.ssh/authorized_keys 需要注意/run/shm/或者/dev/shm的权限问题。最好在根文件系统下单独建立个目录，把shm下的bind过去mount –bind /dev/shm/sshkeys/ /sshkeys/登录的时候可以看到服务端会读取2个authorized_keys文件。 Sep 6 14:24:07 root sshd[17173]: debug1: userauth-request for user root service ssh-connection method publickeySep 6 14:24:07 root sshd[17173]: debug1: attempt 2 failures 1Sep 6 14:24:07 root sshd[17172]: debug1: temporarily_use_uid: 0/0 (e=0/0)Sep 6 14:24:07 root sshd[17172]: debug1: trying public key file /root/.ssh/authorized_keysSep 6 14:24:07 root sshd[17172]: debug1: restore_uid: 0/0Sep 6 14:24:07 root sshd[17172]: debug1: temporarily_use_uid: 0/0 (e=0/0)Sep 6 14:24:07 root sshd[17172]: debug1: trying public key file /sshkeys/.ssh/authorized_keysSep 6 14:24:07 root sshd[17172]: debug1: matching key found: file /sshkeys/.ssh/authorized_keys, line 8~

time-wait其实本来没有啥，但是经常成为让大家恐惧的东西。比如大家一直在试图降低web服务器、代理服务器上的time-wait数量。time-wait本身的作用是提供全双工关闭、过时重复报文段失效，其实也没有什么。唯独是在做反向代理的时候需要特别注意time-wait过多的情况，主要是做代理的时候容易出现tw状态过多把本地端口耗完的情况。一般缓解的方法：1. 改成使用长连接去连后端的服务器。2. 修改ip_local_port_range增加可用的端口范围3. 同时打开tcp_tw_reuse和tcp_timestamps选项，这样收到最后1个包后1s后可以开始重用。这个是在tcp_ipv4.c里定义的 /* With PAWS, it is safe from the viewpoint of data integrity. Even without PAWS it is safe provided sequence spaces do not overlap i.e. at data rates <= 80Mbit/sec. Actually, the idea is close to VJ's one, only timestamp cache is held not per host, but per port pair and TW bucket is used as state holder. If TW bucket has been already destroyed we fall back to VJ’s scheme and use initial timestamp retrieved from peer table. */ if (tcptw->tw_ts_recent_stamp && ...

前几天在国内的某VPS上充了点钱，拿来做测试机器。发现其openssl rsa2048的速度还比较快，说明CPU性能比较好。相比之前我自己的测试服务器理论上直接是物理机测试，单个core的性能却差很多。想了下可能是和openssl、glibc、gcc之类的版本有点关系。但是自己的测试服务器上又不能直接重装其他发行版。想到一起有个debootstrap的工具，就直接在centos的服务器上装了下。使用bashsudo debootstrap –arch amd64 wheezy ./wheezy/ http://centos.ustc.edu.cn/debian/```bash```就可以获得一个wheezy的环境.sudo chroot wheezy /bin/bash后安装一下openssl就可以进行测试。可以直接把多个版本都搞好，然后一个一个测试对比。 [debootstrap](http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/debootstrap-1.0.19-2.el6.noarch.rpm)

先测试了下CPU 跑openssl rsa2048的测试因为都是单核的机器，我就直创建了5个测试了下不同版本的openssl的rsa2048性能 openssl speed rsa2048 -multi 1 OS | |sign/s | verify/subuntu 12.04 | OpenSSL 1.0.1 | 514.464 | 16570.7Ubuntu 12.10 | OpenSSL 1.0.1c|518.936 | 16643.5debian 7 | OpenSSL 1.0.1e | 531.255 | 16881.9fedora 18 |OpenSSL 1.0.1e-fips| 514.936| 16472.8centos 6.4 |OpenSSL 1.0.0-fips|377.027 |12570.8总体看来，centos可能是因为本上的库比较老，openssl的性能差的太多了。我顺便测试了一下4core和8core的VM性能8core:rsa 2048 bits 0.000260s 0.000008s 3840.8 130618.7rsa 2048 bits 0.000251s 0.000008s 3989.4 130098.3rsa 2048 bits 0.000250s 0.000008s 3994.4 129883.1rsa 2048 bits 0.000259s 0.000008s 3868.3 129858.7rsa 2048 bits 0.000257s 0.000008s 3886.1 128886.2rsa 2048 bits 0.000246s 0.000008s 4068.9 128406.2rsa 2048 bits 0.000251s 0.000008s 3981.6 130107.1rsa 2048 bits 0.000246s 0.000008s 4064.1 130652.3rsa 2048 bits 0.000246s 0.000008s 4065.7 129577.9rsa 2048 bits 0.000249s 0.000008s 4012.6 127419.9基本都是500 X 8的性能，4core的时候基本都是2K的性能（500 X4 ），整体还是很多不错的。说明至少自己多花的钱还是有价值的，基本是线性扩展的。 简单测试IO(大文件测试)一般的云主机都是分本地系统盘和另外的另外存储盘。本地盘的性能还算比较好 dd if=/dev/zero of=test1 bs=102400 count=90240 oflag=direct dd if=test1 of=/dev/null bs=102400 count=90240 iflag=direct; 9240576000 bytes (9.2 GB) copied, 70.0601 s, 132 MB/s90240+0 records in90240+0 records out9240576000 bytes (9.2 GB) copied, 21.4463 s, 431 MB/s基本的方案是本地RAID，然后LVM划分给每个VM使用。另外购买的存储盘的大文件速度和本地盘基本相同，下次有时间再测试一下实际的延迟时间是否有大的差异。 ...

传统的VPS厂商对外的时候都会比较忌讳谈超卖的比例。不过linode的FAQ上直接说名的平均的情况，到是挺不错的。How many Linodes share a host? Linodes of the same plan are grouped together onto a host. We adjust the number of slots on each host according to its resources and hardware specification. On average, a Linode 1GB host has 40 Linodes on it. A Linode 2GB host has on average 20. Linode 4GB host: 10 Linodes; Linode 8GB host: 5; 结合到linode的套餐其实就能大概看明白了。 每个宿主机上能跑40个1G的VM（另外比如8G内存的不超过5G），那么说明其宿主机的内存配置还可能就48G的，料想这个FAQ可能只是针对今年升级前的老机型的。老的机型应该是2个Intel(R) Xeon(R) CPU L5520 4core的CPU，配上48G内存，磁盘做raid后容量2T左右。老机型就是把16个逻辑核平均当40个逻辑核卖。从今年最新的blog里面看到现在新的机型都是E5-2670，8core带HT。那么服务器应该内存也应该到64G或者96G了，而且现在的套餐里也多了16G内存的，在之前的48G机型这样会出现跨numa节点的访问，性能会很差。现在每个服务器上逻辑核总数32个，VM的密度不变的话单个宿主机能跑的VM数量可以翻一倍，可以节省很多机架费用(硬件价格不断下降，机架价格像房租一样不断上涨)。现在的每个VM用的都是8个core，看样子应该是开了numa，绑定了每个VM使用的CPU在一个numa节点上，这样只要没有出现跨节点的内存分配的话，VM的性能会比没有开numa的好30%左右。不同套餐的用户使用权重来分优先级。 blog另外从linode的blog上也能看到最新的网络架构，7K+5K+2K，比较常见的架构了。 linode这种做最轻量级的VPS厂商其实还是比较容易的，主要是看公司整体考虑，适当的提高价格，避免控制超卖的比例不够时亏本，类似brust这种超卖应该都是无比严重。。