阅读全文

perl升级引发的一系列惨案

2010年2月21日 18:01

     过年回来,习惯性的emerge -avuDN world升级gentoo,升级过程中出现编译问题,当时没有太在意。和谐,和谐,先正常用吧。可接下来发生的事情把我折腾的够呛。

     首先是VIM不能用了。提示说找不到一个共享库:

     vi: error while loading shared libraries: libperl.so.1: cannot open shared object file: No such file or directory

     $ ldd /usr/bin/vim

     roamin9@matrix ~ $ ldd /usr/bin/vim

        linux-gate.so.1 =>  (0xb780b000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb77a8000)
        libacl.so.1 => /lib/libacl.so.1 (0xb779f000)
        libgpm.so.1 => /lib/libgpm.so.1 (0xb7798000)
        libperl.so.1 => not found
        libutil.so.1 => /lib/libutil.so.1 (0xb7793000)
        libc.so.6 => /lib/libc.so.6 (0xb764a000)
        libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb74f0000)

     看来这个库在升级的过程中没有了。从名字来看,与perl相关。管他三七二十一,先重新emerge一下vim吧。不幸的是,编译vim-core的时候,出错。NND,硬着头皮看出
错信息,感觉是autoconf导致的编译失败(),于是查看autoconf包,发现有两个solt,2.1和2.5。稀里糊涂的决定,先干掉一个吧(杯具的开始):
     # emerge -C =sys-devel/autoconf-2.65

     干掉的很顺利,以后的麻烦却源源不绝。
     查看autoconf版本的方法:
     roamin9@matrix ~ $ WANT_AUTOCONF=2.1 autoconf --version
Autoconf version 2.13
roamin9@matrix ~ $ WANT_AUTOCONF=2.5 autoconf --version
autoconf (GNU Autoconf) 2.65
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.


     在gentoo中,是通过变量WANT_AUTOCONF来控制autoconf的版本,在编译中来使用不同的autoconf。软件包sys-devel/autoconf-wrapper来做切换的事情。


     干掉autoconf-2.65后,发现两个solt的autoconf是必须的,于是想要把autoconf-2.65重新装上,可总是编译出错。问题在哪呢???

     看了下elogv中perl相关的日志,又google了好几下,原来perl升级后,是需要用perl-cleaner来处理一下的。

     # perl-cleaner --all
     看着perl-cleaner自动的找到了需要修复的软件包,万分欢喜,谁曾想它也需要emerge autoconf,出错是注定的了。到现在为止,问题好像已经成了一个圈了。
     看看autoconf的编译失败的日志,忽然间看到"@bolin"的字样提示。@bolin是在我的内核名字中包含的字符串,会不会perl认为@bolin是一个模块名,找不到而引起的错
误呢?

 

使用上了OpenVPN

2009年11月09日 10:31

 

     使用上了yegle同学提供的OpenVPN服务,速度稳定,感觉良好,好久上网没有这么爽快了 :)

   

Cisco VPN Client 引起的诡异故障

2009年11月09日 05:41

    周末无事,想刷一下我的BB(黑莓),遂在Grub中选择了Windows XP,未曾想遇到了一个诡异的网络问题,记录如下。


 

    开机几分钟后,发现浏览器无法打开网页,无论是FF,Opera,还是Chrome,均返回“此网页无法打开”的提示,掉线?可眼光落到右下角,郭的QQ依然坚挺的Online……重启系统,又是几分钟的“生存期”后,网页无法显示,什么情况?

    难道中毒了?查看host文件,进程,都没有发现到可疑。想想自己平时很少使用winXP,也比较注意,于是把病毒的怀疑PASS掉。DNS的问题?打开“CMD”,ping了一下www.gentoo.org,成功返回IP,又尝试的ping了几个网站,都正常返回。想登上路由看看什么情况,发现连路由的页面都无法在浏览器中打开……

   

    感觉很诡异,胡思乱想间认为会不会是G-F-W把我们的外部IP给封掉了,导致我们访问任何网站都会被墙?呵,当然不会,它还顾不上我们,可谁让它那么XX呢,打不开网站习惯性的就想起它。好吧,分析一下,QQ正常,貌似UDP的通信是正常的。而无法打开网页,应该是在TCP协议的通信上出了问题。

    正好在XP中也装了Wireshark,那就打开抓个包看看:

                                                                图一:正常情况下,访问google时的通信

    DNS查询,返回,有来有往,正常的不能在正常了。在看看下副图:

 

                                                               图二:浏览器无法打开网页时,访问douban时的通信

 

    注意看序号为4160的内容,源地址为211.147.4.31,目的地址为209.87.208.60,我们竟然捕获到了“豆瓣”发给209.87.208.60这个目的地址的一条通信内容!看来,我们对“豆瓣”网站的请求,在“豆瓣”进行回应后,我们系统中的一个程序把回应进行了重定向,重定向到了209.87.208.60这个诡异的IP地址上。既然我们与网站之间没有进行正常的通信,网站的页面当然无法打开了!看来原因就在这里。

   

    但这个诡异的IP地址是什么呢?google了一下,原来这个IP属于zonelabs.com,查到了这个地址(Zone Labs Internet Security),据页面所说,你来到这里是有原因di(废话),“伟大”的ZoneAlarm检测到了你目前安装的Zone安全软件出现了问题,有可能是黑客所为,所以它就帮你把你的Internet访问全部阻断,并重定向到了这个页面……

    酱紫啊,可还有两个问题,一,为什么我显示的是“页面无法打开”,而不是重定向到zonelabs.com的提示网页?据我推测,应该和NAT有关,我是在一个路由的后面,请求被重定向到209.87.208.60后,却无法再找到“回来”的路,于是,页面就无法打开了。二,如果我确实使用了ZoneLabs的东西,没有认真看使用说明,发生这种情况我认了,可我压根就没装过任何ZoneLabs的软件呀!带着疑惑再次google,我找到了这个帖子,原来在Cisco VPN Client中使用了Zone的防火墙,而我确实安装了这么个东西,囧。

   

    至此,问题已经大致搞清,如果你也遇到了和我类似的遭遇,去这这看看解决办法吧。我也记下,免得以后被G-F-W。

    进入windows的安全模式,打开注册表,修改:HKEY_LOCAL_MACHINE\System\CurretControl\Set\Services\vsdatant 的值,改为3,保存,重启,Over~~

 

 

PS: Wireshark真是个好东西  :)

 

 

物理服务器迁移至虚拟机

2009年7月23日 23:03

        这几天一直在做一件事,要把众多的物理服务器,迁移至虚拟机中。这样做的目的是用来备份当前系统,当物理服务器的系统发生故障时,可以使用虚拟机中的备份系统,快速的恢复应用。而且,也可以为以后服务器的完全虚拟化做些铺垫。

        闲话少叙,来讲讲我几天实践的经验 :)


        实验前提:

                          物理服务器:OS:   RedFlag   2.4.21-9.30AXsmp   i686

                       

#cat /etc/fstab
LABEL=/      /      ext3   defaults    1 1
LABEL=/boot  /boot  ext2   defaults    1 2
LABEL=/opt   /opt   ext3   defaults    1 2
/dev/sda3    swap   swap   defaults    0 0

 

# df -h
/dev/sda2              14G  2.5G   11G  19% /
/dev/sda1              99M   13M   82M  14% /boot
/dev/sda5             252G  774M  238G   1% /opt

                              虚拟机:VMware GSX Server for linux 3.0

                              宿主OS:CentOS (系统无关紧要)

        所用工具:sysrescuecd,同版本RedFlag的恢复光盘


        一,备份物理服务器中的分区

                话说备份有很多种方式,我只是粗浅知道个大概,就不举例了,等有机会再说。

                这里我使用的工具是fsarchiver(需翻墙)。之所以用它,是因为:

                         1,它备份的是分区上实际使用的文件,而并不是整个分区。而且备份时可以选择压缩级别,大大节省了迁移后在虚拟机中使用的磁盘空间。

                         2,可以识别众多文件系统。(与上面的理由冲突么?)

                         3,可对备份恢复内容进行校验。

                         4,命令简单 :)

                         5,还原时可改变原物理服务器中的文件系统,例如ext3-->reiserfs。

                         6,可把多个文件系统备份到一个文件中去。哇哦

                  此工具包含在sysrescuecd中。用sysrescuecd启动物理服务器自不必多说,要注意的是,在备份过程中,备份的内容是不应该发生改变的!因此,对要备份的分区应该umount,或者mount read-only。

                  fsarchiver其实可以对mount的分区进行备份,但官方并不推荐,应该是还不稳定。如果真能实现,那就太cool了。

 

挂载/opt分区,此次实验中不备份/opt分区,用它只是来存储备份文件。

# mount /dev/sda5 /mnt/backup

备份分区

# fsarchiver savefs /mnt/backup/redflag-bootfs-ext2.fsa /dev/sda1

# fsarchiver savefs /mnt/backup/redflag-rootfs-ext3.fsa /dev/sda2

          

        二,传送备份的文件到VMware Server上去

                就是用scp。可惜fsarchiver不能把备份文件直接保存在NFS分区上,提示有错误(或者是我没搞对?)。不知道还有没有更简便的方法?

 

# scp /mnt/backup/redflag-bootfs-ext2.fsa user@host:/opt/fsarchiver/

# scp /mnt/backup/redflag-rootfs-ext3.fsa user@host:/opt/fsarchiver/

 

        三,获取虚拟磁盘大小

                之前说过,在VMware Server上我们要尽量节省空间,这样才放的下更多的物理系统。因此,我们先看看原来的物理服务器中,实际使用的磁盘空间是多少:

 

# fsarchiver archinfo ./redflag-bootfs-ext2.fsa

# fsarchiver archinfo ./redflag-rootfs-ext3.fsa

                /boot  使用了十几M,/root  使用了3G多空间。知道这些后,我们就可以着手在虚拟机中规划分区,并进行恢复了。

 

给虚拟机划分一块5G的硬盘,进行分区

#fdisk -l /dev/sda
/dev/sda1  /boot  50M
/dev/sda2  swap   500M
/dev/sda3  /      4G

 

 

 

        四,在虚拟机中进行恢复

                用sysrescuecd启动虚拟机,进行恢复。

 

恢复/boot分区,文件系统为ext2
# fsarchiver restfs redflag-bootfs-ext2.fsa id=0,dest=/dev/sda1,mkfs=ext2

恢复/分区,文件系统为ext3
# fsarchiver restfs redflag-rootfs-ext3.fsa id=0,dest=/dev/sda3,mkfs=ext3

                需要重新安装grub。

                当在sysrescuecd中chroot进入系统后,使用应用程序总会发生段错误,应该是和kernel与gcc的版本有关吧。无奈之下,只好使用了同版本的RedFlag恢复光盘,重新启动系统。不过这也带来一个好处,后面会说。

 

进入虚拟机中的系统
# chroot /dev/sda3 /bin/bash

重新安装grub
# grub
>>> root (hd0,0)

>>> setup (hd0)

>>> quit

此时,grub已经重新装在了这块硬盘的MBR上。

 

 

                修改/etc/fstab,以适应新系统的需要。

                兴奋的重启虚拟机,grub正常启动 :) 可在加载内核时,出现了“kernel panic”的错误,显示找不到根分区。肯定是磁盘控制器的驱动没有加载上,该动动initrd了。

 

        五,修改initrd.img文件

                此文件的来历及发展也很有趣,在内核2.4与内核2.6版本中的处理方法也不相同,留到以后有空再聊。现在的目标是让系统中的initrd文件尽快的能用起来。

                我们现在正在RedFlag的恢复光盘中,它为什么可以正常启动系统?显然,它在启动时加载了必须的驱动。我们此时只需要寻找到磁盘控制器的驱动即可。BusLogic: SCSI storage controller。就是他!

 

查看原来initrd.img的内容
# cp /mnt/sda3/boot/initrd.img /mnt/sda3/tmp/initrd.gz
# cd /mnt/sda3/tmp
解压
# gunzip initrd.gz
挂载
# mount -o loop initrd /mnt/sda3/tmp/init
现在就可以看到initrd.img的内容了
# ls /mnt/sda3/tmp/init
bin/ dev/ etc/ lib/ linuxrc* loopfs/ proc/ sbin sysroot/

 

 

                 现在,只需要把驱动拷贝到lib/目录中,并修改linuxrc文件,通知内核加载此驱动即可。

 

# cp /lib/modules/`uname -r`/kernel/drivers/scsi/BusLogic.o /tmp/init/lib

# vi /tmp/init/lib/linuxrc
      #增加必须的模块,去除不需要的模块
      insmod /lib/BusLogic.o

               好了,重新生成initrd.img

 

卸载initrd
# umount /tmp/init

压缩
# gzip initrd

覆盖
# cp initrd.gz /boot/initrd.img
 

                OK,重启……

                问题解决,在启动过程中,RedFlag会启动一个检测程序,检查硬件的变化,并自动配置。

                至此,迁移过程结束,物理服务器中的系统已经在虚拟机中跑的欢畅

 


        遗留的问题:

                              1,自动化处理。只有达到自动化,才有大量迁移的可能。

                              2,网段,光纤存储等问题。

                              3,资源分配问题。

         这次迁移只是一次实验操作,东拼西凑,其中很多地方做得不漂亮,可改进的地方还有很多。但思路应该大致就是这样,您有什么好办法,也说来听听

      

 

 

 

 

 

 

 

       

 

 

 

 

 

 

 

工作一年

2009年7月14日 04:29

    西安的雨停了,天气又重新开始变闷。嗯,来水一篇……

    一年之前应该也在听988电台,里面的主持人嘻嘻哈哈,独自经营着一个热闹的世界。电台外的我也很兴奋,究其原因,自然是获得了一个机会。期望证明自己的那种感觉,高涨的很,那瞬间仿佛看见了未来。经历了08年上半年的考研,地震,找工作等等事情,心里感触颇多。对于地震中逝去的人们,总想起刘墉的一句话,"在那一刻,无论爱恨情仇,他们的故事结束了"。是啊,那些曾经属于他们的故事都结束了,只能告诉自己“愿逝者安息,生者坚强”。彼时彼刻,那个傻傻的许三多仿佛就在耳边说,“有意义的事就是好好活,好好活就是做许多许多有意义的事”。

    回顾起一年来,工作的感觉很新鲜,整个人就像上紧的发条,不断的学习学习。有过苦恼,有过喜悦,也有要感谢的人。我想谢谢秦总的信任,谢谢王经理,谢谢头,你们教会了我很多,也给予了我很多。作为一个刚刚迈入工作的人,我很珍惜这些。也要谢谢我的同事和朋友,一起打蓝球的感觉很棒。当然,也要谢谢郭,给我做了很多的好吃的,你辛苦了。如果能少发点小脾气就完美了。

    第二年的工作有更多的期待,能做的事情有很多,要抓紧时间做好准备了。有什么愿望?嗯,那个,不靠谱的人和事能尽量少一些,哈哈。

    放张图片吧,仔细看,能发现时间的痕迹 :)

第一次打补丁

2009年7月13日 05:52

  说来汗颜,使用Gentoo也有一段时间了,却一直没有自己的Overlay。如果遇到出问题的包,只能……等待。恩 ,懒!

  今天搞Fluxbox的时候,觉得它自带的fbrun不是很好用,于是想尝试一下别人提到的gmrun。无奈RP不高,Portage报告编译失败,遂有此文。记录下我第一次给包打补丁的过程,开始。

  在Gentoo系统中,当包编译失败时,可以去它的bug系统中查查,说不定会有惊喜。这不,我就在此处发现了和我相似的问题。从描述中了解到他找到了解决的办法,并给出了patch。欣喜过后,想起来自己从来没有给包打过补丁,NNDT。

  其实,Gentoo的包管理机制很适合对软件包进行定制,建造自己的软件仓库,当然包括给“不乖”的软件包打上补丁。我是这样做的:

  1,建立自己的Overlay。   

在layman下新建目录,以后你自己的包就存放在这里
$sudo mkdir -pv /usr/local/portage/layman/roamin9
修改layman下的make.conf,加入自己的overlay
$sudo vi /usr/local/portage/layman/make.conf
    PORTDIR_OVERLAY="
    /usr/local/portage/layman/roamin9
    $PORTDIR_OVERLAY"

 

  2,下载patch文件,存入相应ebuild下的files目录下

 

在自己的overlay中,目录结构要与Portage中的相同
$sudo cp -rf /usr/portage/x11-misc/gmrun /usr/local/portage/layman/roamin9/x11-misc
存放patch文件
$sudo cp ./gtkcompletionline.cc.patch /usr/local/portage/layman/roamin9/x11-misc/gmrun/files/
修改相应版本的ebuild文件,添加
$sudo vi /usr/local/portage/layman/roamin9/x11-misc/gmrun/gmrun-0.9.2.ebuild
    epatch "${FILESDIR}"/gtkcompletionline.cc.patch
重新生成ebuild
$ebuild gmrun-0.9.2.ebuild digest
  OK,重新emerge软件包,看到patch已打上,编译过程顺利完成 :)
  

 

 

 

 

小技巧:UUID

2009年7月02日 23:18

以前就一直想知道如何快速的查看一块磁盘分区的uuid,今天偶然看到,记录一下:

 

#ls -l /dev/disk/by-uuid/

 

OK~~

再试一次

2009年6月30日 23:32

  为什么要blog,原因有三:

  一,工作快一年了,这一年中只顾着埋头向前赶,许多知识来不及梳理,便想找一个地方可以记录一些工作与读书过程中的所思所想。

  二,最近感觉有些压抑,需找个途径释放出来,那就用文字吧。

  三,忘记了在哪看到的,“一个人如果不去耕耘,那他就应该写作”。总之,让自己心里感觉舒服一些。

 

  扑通一声,扎进去…