在做linux kernel或者xen hypervisor源码修改的时候,经常会因为一个运行时错误、导致内核宕机,或者根本启动不起来,在一直在自动重启中死循环。以前总是需要跑去机房,在服务器启动到选择内核版本的时候,选择一个正常可用的内核,来启动服务器。

但其实,一种更省事的方式是,用一根串口线将Server1、Server2两台服务器连接起来,将Server1上的BIOS输出、内核输出,都定向到串口上,然后使用ssh登录到Server2上,使用串口工具连接到Server1,即可通过Server2来控制Server1上的启动、选择内核版本、还可以看到Server1上内核的输出信息;

在调试使用jQuery操作checkbox的选中状态切换的时候,发现了个bug:checkbox复选框在被选中再取消选中一次后,无法再次通过jQuery重新选中了。

测试环境:

  • Chrome版本 47.0.2526.106 m
  • Opera版本 34.0.2036.25
  • jQuery版本 V1.11.1

html代码片段如下:

1
2
3
<label><input type="checkbox" name="options" value="1" />样例1</label>
<label><input type="checkbox" name="options" value="2" />样例2</label>
<label><input type="checkbox" name="options" value="3" />样例3</label>

jQeury代码为:

1
2
3
4
5
// 设置全选
$("input[type='checkbox']").attr("checked", "checked");

// 设置取消选中
$("input[type='checkbox']:checked").attr("checked", false);

经过测试, 无论是通过手动选中再取消选中,还是用上述代码设置选中再取消选中,用第一行代码都无法再次选中复选框。

但是使用JavaScript直接操作每一个dom的属性来设置,是可以正常的。这应该算是jQuery的问题吧?

1
2
3
4
$("input[type='checkbox']").each(function() {
this.checked=true; // 设置选中
this.checked=false; // 设置取消选中
})

经网友提示解答,原来是因为jQuery在1.6版本之后,attr方法对checkbox, radio, select等这些表单控件的操作不再特别完善,代替的是prop方法,用prop方法取代attr后,操作结果就正常了。

这件事说来有点不可思议,作为管理员我很惭愧。经过这么长时间与来路不明的黑客的斗法,着实让我深刻体会到了无缝不入的黑客手段能有多危险,如果黑客没有盯着你,只是因为你暂时没有被黑的价值,而不是因为他做不到。

因为此前发见过小规模的挖矿木马,当时在一些服务器上发现有名为./htral的进程,占用400%的CPU资源。当时我们重新整理了iptables的规则,对所有的外网访问都做了严格控制,只有指定的IP才能访问特定的端口。这之后就一直比较太平,没有多少问题反馈,加上自身任务繁忙,对机房的管理比较疏忽,直到最近发现了新的情况。

Read more »

记录服务器上出现过的可以进程,挖矿进程。

虚假[migration进程]

现象: top -c命令查看到一个进程名为[migration]的进程,占用了400%的处理器。看似是系统进程,但是进程号很高,很可疑。
可疑进程

检查: lsof -p $pid查看到如下进程进程信息

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@localhost ~]# lsof -p 32403
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
[migratio 32403 root cwd DIR 8,1 4096 2 /
[migratio 32403 root rtd DIR 8,1 4096 2 /
[migratio 32403 root txt REG 8,1 1253624 401222 /usr/bin/[migration] (deleted)
[migratio 32403 root mem REG 8,1 156936 261670 /lib64/ld-2.12.so
[migratio 32403 root mem REG 8,1 1926760 261672 /lib64/libc-2.12.so
[migratio 32403 root mem REG 8,1 65928 261661 /lib64/libnss_files-2.12.so
[migratio 32403 root 0r FIFO 0,8 0t0 4530871 pipe
[migratio 32403 root 1w CHR 1,3 0t0 3772 /dev/null
[migratio 32403 root 2w CHR 1,3 0t0 3772 /dev/null
[migratio 32403 root 3r REG 8,1 755 1570556 /var/cache/anacron
[migratio 32403 root 4u IPv4 4533256 0t0 TCP localhost:42990->xmr-tmp6.crypto-pool.fr:https (ESTABLISHED)

分析: 进程的可执行文件已经被删除,很可疑。进程链接到了域名:https://xmr-tmp6.crypto-pool.fr 。Google了这个域名后,发现有人反馈其遇到过的一个问题,一个挖比特币进程,运行后也会链接到该域名,http://www.herdprotect.com/gen64.exe-9df28903fd4014286a774471b2c056f9af0489d5.aspx 。因此判断该进程是挖比特币的进程。
域名信息反馈

问题描述

前段时间不断有人反馈的一个问题,集群的入口登陆节点会定期出现几百个ssh和sed进程,导致入口节点非常卡,输入命令严重迟滞。导致无法正常使用。找了好久没有找到原因。严重的时候,只好重启节点,缓解问题。今天问题又出现了,实在不能忍,决定再找找原因看。

Read more »

为了做实验,需要在虚拟机中安装redis并使用redis-benchmark测试性能。 但是在使用redis-benchmark模拟2000个客户端的请求的时候,出现了Could not connect to Redis at localhost:10081: Name or service not known的问题。

Read more »

这里介绍关于Xen性能调整的一些方法,但并不提供具体的调整参数。不同的情况下,最有配置是不一样的。

Read more »