蓝色数据

安装：
apt-get install cvsd
 
配置：
默认的 cvsroot 在 /var/lib/cvsd
改为适合自己的
mkdir /home/cvsroot
cvsd-buildroot /home/cvsroot
这会建立一个 cvsd 的虚拟系统（有如 chroot）。
mkdir /home/cvsroot/repos
初始化代码仓库
cvs -d /home/cvsroot/repos init
使 cvsd 用户/组有权读写代码仓库
chown -R cvsd:cvsd /home/cvsroot/repos
 
接下来修改 /etc/cvsd/cvsd.conf 的配置
RootJail /home/cvsroot
Repos /repos
这里的 /repos 是相对于 cvsd 虚拟系统的 /
 
添加用户：
cvsd-passwd /home/cvsroot/repos bluedata
重启一下
/etc/init.d/cvsd restart
 
客户端的使用：
touch ~/.cvspass
export CVSROOT=:pserver:bluedata@HOST/repos
cvs login
 
附：CVS使用手册

Debian 4.0 (Etch) 发布有一段时间了，今天也把我用了好些年的 Sarge 升级上去了。
apt 实在是很方便。
cat /etc/apt/sources.list
deb http://mirrors.shlug.org/debian/ stable main contrib non-free
deb http://mirrors.shlug.org/debian-security stable/updates main contrib non-free
deb http://mirrors.shlug.org/debian/ proposed-updates main non-free contrib
 
apt-get dist-upgrade
基本只需要按回车使用默认配置就升级完了。
一切都是那么简单，赞一个。

VMware 的安装不是什么难事，基本上是回车即可。
可是在 Debian Sarge 上执行 /usr/bin/vmware-config.pl 生成 vmmon.ko 时却有意外状况发生，说是找不到内核头文件的 scripts 目录。
虽然已经安装过内核头文件，但是想到很久没有更新过内核了，干脆升级一下内核算了。
# apt-get update
# apt-get upgrade
# apt-cache search kernel-image | grep 2.6
安装相应 CPU 型号的最新内核：
# apt-get install kernel-image-2.6.8-3-686-smp
重启进入新内核的系统，确认没有问题后删除老内核：
# dpkg --purge --force-remove-essential kernel-image-2.6.8-2-686-smp
# apt-get remove --purge kernel-headers-2.6.8-2-686
或许 /boot 和 /lib/modules 下的一些残留文件需要另行删除。
再来安装与新内核相匹配的内核头文件：
# module-assistant prepare
再次运行 /usr/bin/vmware-config.pl ，却还是相同的问题。
到 /usr/src/kernel-headers-2.6.8-3-686-smp 目录下一看，发现 scripts 是个链接，是链接到
../kernel-kbuild-2.6-3/scripts 的，而 /usr/src/kernel-headers-2.6.8-3 下的 scripts 也是个链
接，居然同样链接到了 ../kernel-kbuild-2.6-3/scripts ，-_-! 这要不出错才怪了呢。
怀疑是 apt source 的问题，便把 cn99 的换成了 geekbone 的。apt-get clean 后重新安装，可是问题依旧。
询问使用 Debian testing 的用户，说 scripts 是个目录，里面有相应的脚本，看来是 Debian Sarge
的 bug 了。把 Debian testing 2.6.15 内核头文件的 scripts 目录拷贝过来覆盖掉 /usr/src/kernel
-headers-2.6.8-3/scripts 后再运行 /usr/bin/vmware-config.pl ，这次顺利的编译出了 vmmon.ko 。
就在本机使用 VMware 还需在本机安装 VMware-console ，一路回车就搞定。
对于远程使用 VMware ，值得注意的是 Server 和 Client 通信默认使用的是 902 端口，需要在防火墙中打开这个端口。
一个很有意义的设置是虚拟机可以随宿主系统自动启动/关闭：
VM -> Settings... -> Options -> Startup/Shutdown
选择随宿主系统自动启动/关闭。
启动虚拟主机时报错说 /tmp 空间不够，可以给 VMware 指定一个 tmp 目录：
# vi /etc/vmware/config
增加 tmpDirectory="/home/tmp" 。

安装 Oracle 需要在 GUI 下，用 VNC 远程登录比较方便。

对于 Debian ，可以 apt 安装 gnome 和 gdm ，再安装 vncserver ，
然后配置 VNCServer
# vi /etc/vnc.conf
$geometry = "1024x768";
$depth = "16";

启动
$ vncserver :1
停止
$ vncserver -kill :1
修改密码
$ vncpasswd

对于 Redhat ，安装系统的时候选上 GNOME 桌面。
VNCServer 的配置
# vi /etc/sysconfig/vncservers
VNCSERVERS="1:root 2:oracle"
VNCSERVERARGS[1]="-geometry 1024x768"
执行 vncserver ，会要求设置连接密码。接下来 $HOME/.Xauthority 文件和 $HOME/.vnc 目录也就创建了。

之后可以使用
# /etc/init.d/vncserver stop
# /etc/init.d/vncserver start
来关闭和启动服务。

$HOME/.vnc/xstartup 执行 X 启动时的设置，如果要启动 GNOME 可以加入 gnome-session ，而要启动 KDE 的话可以加入 startkde 。如果设置了开机自动启动，vncserver 还没有得到语言的环境变量，远程登录后是英文界面，可以在 xstartup 中加入“LANG="zh_CN.GBK" export LANG”。配置文件的一个范例：
# cat $HOME/.vnc/xstartup
#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

LANG="zh_CN.GBK"
export LANG

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
gnome-session
#startkde

以前用网关路由器拨号上网时使用微软的东西是没有问题的。现在换成用 Debian 拨号再使用 iptables SNAT 后，MSN 就不能登陆了，打开 www.msn.com.cn 非常慢且只能打开页面的头部，而 windowsupdate.microsoft.com 根本就打不开了。
 
google 后得知修改 PC 网卡的 MTU 值可以解决这个问题。
在 Windows 2000/XP 下修改注册表：
『HKEY_Local_Machine』->『SYSTEM』->『CurrentControlSet』->『Services』->『Tcpip』->『Parameters』->『interface』
找到所使用的网卡，『编辑』->『新增』->『DWORD值』之后，建立一个名为『MTU』的机码，右键『修改』，选择十进制，填入 1480 。
 
但是，这个方法很蹩脚呢，内网中的机器那么多，一个一个去改是很不现实的。
对网关进行修改才是正道。
 
在网关服务器上，
# ip addr sh
发现 ppp 设备的 mtu 值是 1492 。
就在 /etc/ppp/peers/dsl-provider 文件中取消了“mtu 1492”这行的注释并改为了 1480 ，重新拨号却没有变化。在 /var/log/messages 中还看到这样的信息：
Couldn't increase MTU to 1500
Couldn't increase MRU to 1500
没有设置 mtu 值的时候也会有这样的信息，这就意味着 pppoe 忽略了 mtu 这个参数。
 
没办法，继续 google ，有说 plugin rp-pppoe.so 有 bug ，就注释掉这行，改用
pty "/usr/sbin/pppoe -I eth1 -T 80 -m 1480"
结果根本不能拨号了。-_-!
软的不行就来硬的，直接
# ifconfig ppp0 mtu 1480
这下 MSN 能登陆了，但是微软的网站还是打不开。
 
注：Redhat 可以修改 /etc/sysconfig/networking-script/ifcfg-ppp0 ，添加 CLAMPMSS=1480 。
 
最后的解决办法——用 iptables 改 MTU 值。
# iptables -A FORWARD -o ppp0 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j
TCPMSS --clamp-mss-to-pmtu
把出站包大小改为 ppp0 的 MTU 尺寸，这下就一切正常了。
MSS 既 Max Segment Size 。
 
参考资料：鸟哥的 Linux 私房菜——连不上一些网站的处理方法 MTU 修改
 
 
另记：
由于 Microsoft Windows 系列操作系统传送的 TCP 包请求的 segment 太大，超出了 PPPoE 的 frame 所能够接受的范围，导致 PPPoE 传送“don't fragment”的 ICMP 而不是“must fragment”，最终导致网站没有响应。这种情况称为“Black Hole Router”。
—— 2006.05.13 00:30
 
又看了一下 /etc/ppp/ip-up.d 下的脚本，发现 0clampmss 里的内容是这样的：
#!/bin/sh
# Enable MSS clamping (autogenerated by pppoeconf)
iptables -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
看来 Debian 的 pppoe 也早有考虑。我在做 SNAT 前清空了 iptables 规则，造成 pppoe 添加的 iptables 规则失效了。
—— 2006.06.01 13:48