最近有同学找到我,说是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进系统去把分区挂载起来,然后单独把链接恢复.
今天有同学不小心在/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 "
线上经常因为系统盘的故障或者是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~
前几天在国内的某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使用。另外购买的存储盘的大文件速度和本地盘基本相同，下次有时间再测试一下实际的延迟时间是否有大的差异。 ...
做运维的都知道，最怕的不是机器直接挂掉，而是怕机器hang在那里，能ping通但是又登录不上去。周末加班写了个检测脚本，发送icmp包进行ping的检查，如果有返回再继续做ssl端口的检查或者ssh登录的检查。python不像perl下直接有个很好用的net::ping，自己网上找了个python-ping，修改了一下放脚本里面直接用。 #!/usr/bin/env python2.7 import socket import sys import paramiko import os import select import struct import time import threading import Queue import copy import string import hashlib from collections import deque ICMP_ECHO_REQUEST = 8 # Seems to be the same on Solaris. class CheckHang: def init(self,server): self.server=server def check_ssh(self): """ return 1 when i can’t ssh to the server """ ssh = paramiko.SSHClient() key = paramiko.RSAKey.from_private_key_file("/home/pm/keys/id_rsa") ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: ssh.connect(self.server,username=“root”,pkey=key,timeout=1) flag=1 ssh.close() except: flag=0 return flag def check_ssh_port(self,port): """ check the 22 port alive, return 1 when the port is alive. """ port_test = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: port_test.settimeout(1) ...
最近拿到的几个12块盘的服务器，都是没有RAID卡的。自己就简单做了一下软RAID。 用/dec/sd[b-l]1创建一个raid10的/dev/md1，其中一个做备用盘。 mdadm –create /dev/md1 –run –level=10 -n 10 /dev/sd[b-l] -x 1 mkdir /mnt/data ; mkfs.ext4 /dev/md1 2.把mda1加到fstab/dev/md1 /mnt/data ext4 defaults,noatime 0 03.把阵列信息加到/etc/mdadm.confmdadm –detail –scan » /etc/mdadm.conf 状态查看可以 #cat /proc/mdstat Personalities : [raid10] md1 : active raid10 sdl[10](S) sdk[9] sdj[8] sdi[7] sdh[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1] sdb[0] 9767564800 blocks super 1.2 512K chunks 2 near-copies [10/10] [UUUUUUUUUU] unused devices: #mdadm –detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Sat Jul 20 00:33:49 2013 Raid Level : raid10 Array Size : 9767564800 (9315.08 GiB 10001.99 GB) Used Dev Size : 1953512960 (1863.02 GiB 2000.40 GB) Raid Devices : 10 Total Devices : 11 Persistence : Superblock is persistent ...
最近在做些打杂的事情，需要对dns做一下健康检查。脚本直接shell写的，以前的同事的方案只是直接检查一下named进程是否存在，存在就是表示OK的，这个策略显然是有问题的，比如进程假死之类的其实是没有办法检查的。然后我就想着改成nslookup或者host命令进行一个查询，检测返回值，由于nslookup的返回值不能体现出查询是否成功，就只有host可以用了。```bash check_dns(){local domainlocal serverdomain=“www.xxx.com"server=’127.0.0.1′ host -W1 $domain $server &>/dev/nullerror=$?if [ $error -ne $STATUS_OK ];thenwarn "can’t resolve $domain,error."fireturn $error} check_dns(){local domainlocal serverdomain="www.xxx.com"server=’127.0.0.1′dig @$server $domain +time=1 +retry=1 +tries=1 &>/dev/nullerror=$?if [ $error -ne $STATUS_OK ];thenwarn "can’t resolve $domain,error."fireturn $error
公司使用的svn都是1.7版本的，然后在debian testing源里的版本还是1.6的，这个就造成了平时在linux下完全不能用svn。晚上升级了一下，终于可以用了。直接加一下源:deb http://opensource.wandisco.com/debian/ squeeze svn17添加一下key```bash wget http://opensource.wandisco.com/wandisco-debian.gpgsudo apt-key add wandisco-debian.gpg
今天群里有同学说编译内核出了点问题。我一想大概一年过没有自己编译过内核了，现在内核版本号飙升的非常快，转眼都过了3.8了。就下了一个随便编译了一下。现在的都是xz压缩的，解压时可以这样```bash tar -J –xz -xvf linux-3.8.4.tar.xz