wd and cc » Linux

昨天和 sssslang 和 xwl 聚了个会

wd — Sun, 29 Nov 2009 04:34:19 +0000

和 sssslang 倒是很早就见面来着，好像是他那会刚回北京？聊了聊 linux 相关的东西，呵呵。

说起来 linux 用户也挺郁闷的，平时旁边没几个用的，就算是用的，好像也都是 ubuntu 用户，基本就是当 windows 用的，很少主动去挖掘 linux 的一些东西，这些用户比较务实，主要还是在工作方面，开发的东西也都是工作相关的，比较少去做一些无聊的开发。。。所以和他们好像也没什么好聊的。

前两天 #emacs-cn 的 xwl 提议聚会，大家一拍即合，呵呵，定了时间地点，那就聚一个。

聊的东西基本围绕在 emacs， linux， mac 上面。最主要的是 xwl 秀了下他的小黑 macbook 和他的 emacs，sssslang 倒是很详细的问了下 xwl 用的 elisp 扩展，可我对那些不是很明白，我觉得 elisp 就是一个变态的语言。。。对我来说，还记得的可能有下面几个吧。

1 他的 emacs 的标题会显示宋词，会定时变化。
2 有个渐变的扩展，叫做 highlight tail 的，很 cool 吸引小 mm 的必备啊，呵呵。
3 他用了很多定时器，比如执行完编译后，会 split 出来一个新的窗口显示一些编译信息，如果没有错误，那等 3 秒，这个窗口就会自动关掉。还有 1 里面说的那个，也是定时器弄的。
4 有个叫 woman 的东西不错。
5 xwl 和 sssslang 一直强调 ido 是个很不错的东西，不过我是不太明白的。呵呵。
6 xwl 设置打开文件默认就进只读，因为一般来说打开文件都是看看，同时也不可能写很多文件。只读后，还能设置很多单键的快捷键，比如 vim 里面的 hjkli 这些，这样让 emacs 变的有模式起来，我觉得很 cool。不过居然没有别人想到么？那应该有个 vimoper-mod 吧。。。
7 还有个用来画图的 graphviz 很 cool 的。

因为 xwl 用的是 mac，linux 也就是我和 ssslang 了，ssslang 没有本带，基本就是我秀了下我的 kde，openbox，conky 这些，好像也没别的了。说到 linux 有个郁闷的，就是我没使用什么 networkmanager，wicd 之类，都是手动配置的 wpa_supplicant ，这样就需要知道 wifi 的 key 的类型什么的，没办法得到的话就只能猜，很不方便。人家 mac， windows， s60 都连上 wifi 上网了，我这还在猜 key 的类型。。。刚发现，iwlist 实际是能显示 key 信息的。

mac 的效果还是很不错的，国内的很多 mac 用户真是白瞎了这个尤物了，装什么 windows。xwl 可真是 apple 的忠实 fans，花 200 块钱升级系统。。。

说了这么多，我感觉我很像是去打酱油的。。。

说实话 Starbuck 的咖啡好像也不怎么样。。。尤其一会就凉了。。很郁闷，不过回来和老婆说，老婆说：你个傻子，就不知道点一个冰的啊。。。是啊，我为什么没点一个冰的呢？。。。。

万恶的 ATI fglrx 驱动

wd — Fri, 04 Jul 2008 13:36:08 +0000

ATI 官方驱动带了一个 amdcccle 命令，可以显示图形界面对显示器作一些设置，例如修改分辨率，twinview, dual head, bigdesktop 这些设置。其实 nvidia 的官方驱动也是带了这么一个工具的。

但是呢，有时候就会发现，通过这个命令修改显示之后，你的xorg.conf 里面的设置就不起作用了！无论你之后如何去修改你的 xorg.conf ，他根本不会去理会。

我遇到的问题就是，某次通过 amdcccle 设置了一下 bigdesktop，结果导致接上我的另外一个LCD之后，那个LCD的分辨率死活就卡在 1024×768 上了。要知道，那个LCD是支持 1280×1024的，可是无论如何设置，就是不能提高分辨率了。查看 xorg 的log，能看到读取的 /etc/X11/xorg.conf 文件，可是就是没效果。

开始怀疑是显示器出于保护，把分辨率设置底了，结果接到别人的笔记本上面是没问题的。后来研究来研究去，发现还是 ATI 驱动的问题。

/etc/ati 下面有不少文件，也不知道这些文件是什么用途，但是 amdpcsdb 这个文件就是罪魁祸首了。删掉后LCD的分辨率就正常了。

很奇怪，我执行 amdcccle 的时候，用的可不是 sudo ，他是怎么写到这个文件里面的？

自动登录网站的 greasemonkey 脚本

wd — Sun, 22 Jun 2008 13:04:17 +0000

自动登录 gmail 的 greasemonkey 脚本，可以根据需要修改 formElement.name==”Email” 为别的，来登录别的网站。注意修改 name, include 这些相关的东东

// (c) 2007, Yabin Guo
// To install, you need Greasemonkey: http://greasemonkey.mozdev.org/
//
// --------------------------------------------------------------------
// ==UserScript==
// @name          gmail Login
// @description   Auto-login of gmail
// @include       https://www.google.com/a/wdicc.com/*
// ==/UserScript==
 
//replace your seraph username and password in the following expression;
userName="wd";
passWord="*******";
 
function submitFirstPasswordForm() {
	var form=document.forms[0];
    var submitButton = null;
	var passwordElem;
	var accountElem;
	var submitButton;
    for (i=0; formElement=form[i]; ++i){
		if(formElement.type=="password"){
			passwordElem=formElement;
		}else if(formElement.name=="Email"){
			accountElem=formElement;
		}else if(formElement.type=="submit"){
			submitButton=formElement;
		}
	}
 
	accountElem.value=userName;
	passwordElem.value=passWord;
 
    if (submitButton) {
        submitButton.focus();
        submitButton.style.MozOutline = "2px solid purple";
        // Submit the form by calling click() on the submit button.
        submitButton.click();
        // Break out of both loops.
        return; 
      }
}
 
window.addEventListener(
  "load", 
  function() { 
    setTimeout(submitFirstPasswordForm, 0); 
  }, 
  false
);

PING命令中TTL的具体含义zz

wd — Wed, 30 Aug 2006 06:22:50 +0000

有台服务器ping的时候老出现 Time to live exceeded 这个错误，这样就会误报服务器挂掉，很烦人。找了半天似乎找到了解决方法了。

ping的时候返回的包的ttl值是根据对方系统的设置来的，默认情况下，win是128,linux是64,返回的时候，每经过一个节点，就减1,这样，根据返回包的ttl值就可以判断经过了几个路由节点。而节点要是比较多的话，会导致这个ttl值为0,这样就出现上面提到的问题了。当然，要是遇到包进了环路，也会产生这样的问题，详细的内容可以看下面的转载文章。

这样，解决这个问题的方法就是修改对方系统的默认ttl 值，比如修改为255，这样如果还产生上面的错误的话，那就没准是哪里的问题了。呵呵。

Linux下修改方法:

方法1(重启后有效)：
#sysctl -w net.ipv4.ip_default_ttl=N
(N=0~255),若N>255,则ttl=0
方法2(重启后无效)：
#echo N(N为0～255) > /proc/sys/net/ipv4/ip_default_ttl

原文地址：这里

PING命令中TTL的具体含义
提供者 vitty简单来说，TTL全程Time to Live，意思就是生存周期。
首先要说明ping命令是使用的网络层协议ICMP，所以TTL指的是一个网络层的网络数据包（package）的生存周期，这句话不懂的先回去复习OSI7层协议去。

第一个问题，为什么要有生存周期这个概念。

很显然，一个package从一台机器到另一台机器中间需要经过很长的路径，显然这个路径不是单一的，是很复杂的，并且很可能存在环路。如果一个数据包在传输过程中进入了环路，如果不终止它的话，它会一直循环下去，如果很多个数据包都这样循环的话，那对于网络来说这就是灾难了。所以需要在包中设置这样一个值，包在每经过一个节点，将这个值减1，反复这样操作，最终可能造成2个结果：包在这个值还为正数的时候到达了目的地，或者是在经过一定数量的节点后，这个值减为了0。前者代表完成了一次正常的传输，后者代表包可能选择了一条非常长的路径甚至是进入了环路，这显然不是我们期望的，所以在这个值为0的时候，网络设备将不会再传递这个包而是直接将他抛弃，并发送一个通知给包的源地址，说这个包已死。
其实TTL值这个东西本身并代表不了什么，对于使用者来说，关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。但是TTL值还是可以得到有意思的信息的。

每个操作系统对TTL值得定义都不同，这个值甚至可以通过修改某些系统的网络参数来修改，例如Win2000默认为128，通过注册表也可以修改。而 Linux大多定义为64。不过一般来说，很少有人会去修改自己机器的这个值的，这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。

以我公司2台机器为例
看如下命令
D:Documents and Settingshx>ping 61.152.93.131

Pinging 61.152.93.131 with 32 bytes of data:

Reply from 61.152.93.131: bytes=32 time=21ms TTL=118
Reply from 61.152.93.131: bytes=32 time=19ms TTL=118
Reply from 61.152.93.131: bytes=32 time=18ms TTL=118
Reply from 61.152.93.131: bytes=32 time=22ms TTL=118

Ping statistics for 61.152.93.131:
Packets: Sent = 4， Received = 4， Lost = 0 (0% loss
Approximate round trip times in milli-seconds:
Minimum = 18ms， Maximum = 22ms， Average = 20ms

D:Documents and Settingshx>ping 61.152.104.40

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.104.40: bytes=32 time=28ms TTL=54
Reply from 61.152.104.40: bytes=32 time=18ms TTL=54
Reply from 61.152.104.40: bytes=32 time=18ms TTL=54
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54

Ping statistics for 61.152.104.40:
Packets: Sent = 4， Received = 4， Lost = 0 (0% loss
Approximate round trip times in milli-seconds:
Minimum = 13ms， Maximum = 28ms， Average = 19ms
第一台TTL为118，则基本可以判断这是一台Windows机器，从我的机器到这台机器经过了10个节点，因为128-118=10。而第二台应该是台Linux，理由一样64-54=10。
了解了上面的东西，可能有人会有一些疑问，例如以下：

1，不是说包可能走很多路径吗，为什么我看到的4个包TTL都是一样的，没有出现不同？

这是由于包经过的路径是经过了一些最优选择算法来定下来的，在网络拓扑稳定一段时间后，包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了，不在讨论之列。

2，对于上面例子第二台机器，为什么不认为它是经过了74个节点的Windows机器？因为128-74=54。

对于这个问题，我们要引入另外一个很好的ICMP协议工具。不过首先要声明的是，一个包经过74个节点这个有些恐怖，这样的路径还是不用为好。

要介绍的这个工具是tracert（*nix下为traceroute），让我们来看对上面的第二台机器用这个命令的结果
D:Documents and Settingshx>tracert 61.152.104.40

Tracing route to 61.152.104.40 over a maximum of 30 hops

1 13 ms 16 ms 9 ms 10.120.32.1
2 9 ms 9 ms 11 ms 219.233.244.105
3 12 ms 10 ms 10 ms 219.233.238.173
4 15 ms 15 ms 17 ms 219.233.238.13
5 14 ms 19 ms 19 ms 202.96.222.73
6 14 ms 17 ms 13 ms 202.96.222.121
7 14 ms 15 ms 14 ms 61.152.81.86
8 15 ms 14 ms 13 ms 61.152.87.162
9 16 ms 16 ms 28 ms 61.152.99.26
10 12 ms 13 ms 18 ms 61.152.99.94
11 14 ms 18 ms 16 ms 61.152.104.40

Trace complete.

从这个命令的结果能够看到从我的机器到服务器所走的路由，确实是11个节点（上面说10个好像是我犯了忘了算0的错误了，应该是64-54+1，嘿嘿），而不是128的TTL经过了70多个节点。
既然已经说到这里了，不妨顺便说说关于这两个ICMP命令的高级一点的东西。
首先是ping命令，其实ping有这样一个参数，可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。
例如还是用那台Linux机器，用以下命令：
D:Documents and Settingshx>ping 61.152.104.40 -i 11

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.104.40: bytes=32 time=10ms TTL=54
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54
Reply from 61.152.104.40: bytes=32 time=10ms TTL=54
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54

Ping statistics for 61.152.104.40:
Packets: Sent = 4， Received = 4， Lost = 0 (0% loss)，
Approximate round trip times in milli-seconds:
Minimum = 10ms， Maximum = 13ms， Average = 11ms

D:Documents and Settingshx>
这个命令我们定义了发包的TTL为11，而前面我们知道，我到这台服务器是要经过11个节点的，所以这个输出和以前没什么不同。现在再用这个试试看：
D:Documents and Settingshx>ping 61.152.104.40 -i 10

Pinging 61.152.104.40 with 32 bytes of data:

Reply from 61.152.99.94: TTL expired in transit.
Reply from 61.152.99.94: TTL expired in transit.
Reply from 61.152.99.94: TTL expired in transit.
Reply from 61.152.99.94: TTL expired in transit.

Ping statistics for 61.152.104.40:
Packets: Sent = 4， Received = 4， Lost = 0 (0% loss)，
Approximate round trip times in milli-seconds:
Minimum = 0ms， Maximum = 0ms， Average = 0ms

D:Documents and Settingshx>

可以看到，结果不一样了，我定义了TTL为10来发包，结果是TTL expired in transit.就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip，这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip，包的TTL就是在这里减少到0了，根据我们前面的讨论，当TTL减为0时设备会丢弃包并发送一个TTL过期的ICMP反馈给源地址，这里的结果就是最好的证明。
通过这里再次又证明了从我机器到服务器是经过了11个节点而不是70多个，呵呵。
最后再巩固一下知识，有人可能觉得tracer这个命令很神奇，可以发现一个包所经过的路由路径。其实这个命令的原理就在我们上面的讨论中。

想象一下，如果我给目的服务器发送一个TTL为1的包，结果会怎样？
根据前面的讨论，在包港出发的第一个节点，TTL就会减少为0，这时这个节点就会回应TTL失效的反馈，这个回应包含了设备本身的ip地址，这样我们就得到了路由路径的第一个节点的地址。
因此，我们继续发送TTL=2的包，也就受到第二个节点的TTL失效回应

依次类推，我们一个一个的发现，当最终返回的结果不是TTL失效而是ICMP Response的时候，我们的tracert也就结束了，就是这么简单。

顺便补一句ping命令还有个-n的参数指定要发包的数量，指定了这个数字就会按照你的要求来发包了而不是默认的4个包。如果使用-t参数的话，命令会一直发包直到你强行中止它。

死在了fsck手里

wd — Fri, 28 Jul 2006 12:58:24 +0000

上周六断电，一台dhcp server挂了，启动的时候提示硬盘有问题，让fsck修复一下。每次启动都提示，而且在这里会停下来，很烦。那就fsck一下吧，结果。。。系统就进不去了。埃，之前还好还能进去，真郁闷。

所以，fsck之前，一定要先把重要的东西都导出来再说。

fsck的命令的几个使用方法

指令：fsck
使用权限 : 超级使用者
使用方式 : fsck [-sACVRP] [-t fstype] [--] [fsck-options] filesys [...]
说明：检查与修复 Linux 档案系统，可以同时检查一个或多个 Linux 档案系统

参数：
filesys ： device 名称(eg./dev/sda1)，mount 点 (eg. / 或 /usr)
-t : 给定档案系统的型式，若在 /etc/fstab 中已有定义或 kernel 本身已支援的则不需加上此参数
-s : 依序一个一个地执行 fsck 的指令来检查
-A : 对/etc/fstab 中所有列出来的 partition 做检查
-C : 显示完整的检查进度
-d : 列印 e2fsck 的 debug 结果
-p : 同时有 -A 条件时，同时有多个 fsck 的检查一起执行
-R : 同时有 -A 条件时，省略 / 不检查
-V : 详细显示模式

-a : 如果检查有错则自动修复
-r : 如果检查有错则由使用者回答是否修复

例子 :
检查 msdos 档案系统的 /dev/hda5 是否正常，如果有异常便自动修复 :
fsck -t msdos -a /dev/hda5

注意 :

此指令可与 /etc/fstab 相互参考操作来加以了解。