存档

文章标签 ‘rhel’

CentOS并入RedHat后对大家操作系统的选择的影响

2014年8月13日 没有评论

众所周知,今年年初,CentOS并入了RedHat公司,这对整个开源操作系统市场的影响是巨大的,虽然RedHat还承诺CentOS会继续免费,很多CentOS的用户以及打算使用CentOS的用户纷纷担心CentOS的前途。实际上,用脚趾头都能想明白:免费的CentOS都这么好用了,谁还会去买花钱而且还巨贵的rhel(RedHat enterprise advance server)呢?为了避免这个,RedHat只会让CentOS越来越难用,越来越不好用才对。所以,原本打算采用CentOS的人开始重新考虑他们的选择,而CentOS的用户,又在考虑有CentOS的替代方案。
我这里就大概给原来rhel或CentOS用户估计一下可用的替代方案。
替代方案一:SL(Scientific Linux)
Scientific Linux其实跟CentOS一样,也是拿着rhel放出来的源代码重新build的Linux发行版,所以,这应该是最切换最容易的解决方案。可这个方案的问题在于,Scientific Linux实在是太小众了,用的人太少。
替代方案二:Ubuntu server
Ubuntu server是最近今年最风头无限的Linux发行版(没有之一)。OpenStack是首先在ubuntu平台上测试并推荐运行的;docker也是首先推荐运行在ubuntu上的。由此,我们大致可以认为ubuntu是未来的大家选在Linux版本的大热门。Ubuntu的问题同样很明显,他跟rhel是完全两个不同的流派(RedHat系和Debian系),开发人员、运维人员从RedHat系转到Debian系可能需要一个过程。
替代方案三:Debian
既然提到了Ubuntu server,那就不能不提Debian。Ubuntu就是在Debian的版本基础上开发的,从这种意义上来讲:Debian比Ubuntu还要稳定一些。同样,Ubuntu的问题也是Debian无法回避的。
替代方案四:FreeBSD
替代方案五:自制Linux发行版
……

升级浪潮英信服务器rs5220的kernel从2.6.18-128到2.6.18-194

2011年6月18日 没有评论

  浪潮英信服务器rs5220的raid卡的驱动开始支持rhel5.5了,于是我也酝酿着讲服务器的kernel从2.6.18-126(rhel5.3,或centos5.3的kernel版本)升级到2.6.18-194(rhel5.5或centos5.5的kernel版本)
  我现有的环境是centos5.6 for x86_64,kernel 2.6.18-128.el5(其实就是centos5.3的系统,后来yum upgrade到了5.6,又用老kernel起起来系统……)
具体步骤如下:

cd /tmp
cp megasr-13.17.0421.2010-1-rhel50-u5-all.img /tmp
#上面的xxxxxx.img就是浪潮给的rhel5.5的raid卡驱动
mkdir temp
mount -o loop megasr-13.17.0421.2010-1-rhel50-u5-all.img temp/
cd temp/
cp modules.cgz ../
cd ..
mv modules.cgz modules.gz
gzip -d modules.gz 
mkdir temp1
cd temp1
cpio -dumi < ../modules
cd 2.6.18-194.el5/x86_64/
mkdir -p /lib/modules/2.6.18-194.el5/updates/
cp megasr.ko /lib/modules/2.6.18-194.el5/updates/
vim /etc/yum.repos.d/CentOS-Base.repo 
#这一步是为了把yum的repo指向centos5.5的安装树,这样的话好直接安装centos5.5的kernel:2.6.18-194.el5
yum -y install kernel-2.6.18-194.el5
reboot

  上面个啥都没讲,就写命令了,其实,里面还是有些道道的。比如:我先把驱动放在合适的位置上后再安装新的kernel。这也算是我灵机一动后的产物,传统的想法自然是先安装新kernel,再把驱动放到合适的位置,但这样有问题,问题在于装新kernel的时候会出错,因为系统在做mkinitrd操作时找不到相应新版本的megasr.ko,当然啦,按照传统的思路是把驱动放好之后再重新mkinitrd。但是为什么不直接先放好megasr.ko,然后安装新kernel时让其自动一次就做了mkinitrd呢?对呀,为什么不呢?于是就先创建了新驱动要呆的路径,把驱动放进去,再安装新kernel。

rhel5.3的yum的错误

2010年7月22日 没有评论

今天在一台rhel(redhat enterprise linux)5 update 3的机器上yum装东西
突然发现出错了
连yum update也出错,错误像下面这样:
Traceback (most recent call last):
File “/usr/bin/yum”, line 29, in ?
yummain.user_main(sys.argv[1:], exit_code=True)
File “/usr/share/yum-cli/yummain.py”, line 229, in user_main
errcode = main(args)
File “/usr/share/yum-cli/yummain.py”, line 145, in main
(result, resultmsgs) = base.buildTransaction()
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 647, in buildTransaction
(rescode, restring) = self.resolveDeps()
File “/usr/lib/python2.4/site-packages/yum/depsolve.py”, line 696, in resolveDeps
CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors)
File “/usr/lib/python2.4/site-packages/yum/depsolve.py”, line 779, in _resolveRequires
thisneeds = self._checkInstall(txmbr)
File “/usr/lib/python2.4/site-packages/yum/depsolve.py”, line 851, in _checkInstall
provs = self.tsInfo.getProvides(*req)
File “/usr/lib/python2.4/site-packages/yum/transactioninfo.py”, line 432, in getProvides
result.update(self.getNewProvides(name, flag, version))
File “/usr/lib/python2.4/site-packages/yum/transactioninfo.py”, line 414, in getNewProvides
for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems():
File “/usr/lib/python2.4/site-packages/yum/packageSack.py”, line 300, in getProvides
return self._computeAggregateDictResult(“getProvides”, name, flags, version)

最有
重新yum clean all后好了
问题真奇怪

分类: TroubleShooting 标签: , , ,

fecora下的000-delay.cron

2009年12月18日 没有评论

fedora core系列的linux
其crontabs的rpm包里都包含有个文件
/etc/cron.daily/000-delay.cron
同时还有/etc/cron.monthly/000-delay.cron和/etc/cron.weekly/000-delay.cron两个软链到这个文件
这个东东是干嘛的呢
他是把每天、每周、每月在cron里定时要干的事情随机的延时一定时间
这个延时的时间随机启名不同而不同
范围在0~4095之间
这是为嘛呢
就是怕多台服务器同时干一件事情而引发相应的问题
比如
我管理有4000台服务器
所有的cron里都是每天晚上1点ntpdate对时
那么每天晚上1点时,ntp server的负载就会非常之大
而且还有可能影响来对时的服务器不能正确及时地取会结果
从这点来讲
这个000-delay.cron还是有点用处的
但是从logrotate来讲
就有些问题了
比如,我一堆web服务器
需要每天晚上同一个时间rotate其access_log
然后把这些log搞到一起分析才有意义
要不然有的机器先rotate,有的后做
那log分析就不好做了

还好
貌似rhel5中的crontabs包里没有这个东东

诡异现象:echo一个字串都会导致ssh sesion退出

2009年4月27日 1 条评论

就好像是敲入exit命令或Ctrl+D一样
奇怪的是
在我的两台rhel as5的机器上有这个问题
在另外两台fedora core的机器上就没问题
貌似可能还不是echo的版本的问题(2台fc,一台是”echo (GNU coreutils) 5.2.1″,一台是”echo (GNU coreutils) 6.9″,都没问题)
两台有问题的rhel as5都是”echo (GNU coreutils) 5.97″

貌似跟shell有关系
我换了tcsh和 zsh都没问题
然后再敲bash回bash
再echo的话
就报”Segmentation fault”

启动sendmail时出错:“sql_select option missing”

2009年4月21日 没有评论

升级了一台rhel as4u7到rhel as5u3
启动sendmail时/var/log/messages里记错:

sql_select option missing
auxpropfunc error no mechanism available

rpm -qa | grep cyrus-sasl
发现有个cyrus-sasl-sql软件包
rpm -e cyrus-sasl-sql
删掉即可

rhel的半官方源EPEL

2009年2月12日 2 条评论

公司服务器大多是rhel(Red Hat Enterprise Linux)的as(Advance Server)
这个版本有个缺点
就是官方源里的软件比较少
很多很多好用的新的gnu的软件都没有包含进去
如:nginx等等等等
于是
EPEL(Extra Packages for Enterprise Linux)出现了
EPEL是fedora社区志愿维护的一个rhel的软件仓
里面全是一些非常新的、非常好用的但rhel官方源里又没有的软件
因为是fedora社区维护的
所以称之为“半官方”
这个新的源又怎么用呢
很简单

su -c ‘rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm’
如果你是rhel4的系统地话
su -c ‘rpm -Uvh http://download.fedora.redhat.com/pub/epel/4/i386/epel-release-4-9.noarch.rpm’
相应你如果是x86_64的系统呢
su -c ‘rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm’
su -c ‘rpm -Uvh http://download.fedora.redhat.com/pub/epel/4/x86_64/epel-release-4-9.noarch.rpm’

然后
就可以用yum安装东西了
比如:

yum install nginx

upgrading from as4 to as5 online(success!)

2008年12月16日 2 条评论

又一次干脏活
把某一台rhel4(as4)的机器在线升级到rhel5(as5)
as4上原来的包管理用的是第三方的apt(apt不在我们的as5的repos仓里)
由于有了上一次的经验
这一次我先稳打稳扎
先用

apt-get update;apt-get check;apt-get -y upgrade;apt-get -y dist-upgrade

先把系统升级成as4的最新版
如果升级了kernel还需要用新kernel重起
(其实最后看起来这一步实属多余,而且还可能添加更多的麻烦,其实只是需要安装as4的最新的kernel即可的)
然后正式开始升级工作
首先

rpm -Uvh http://10.0.0.1/pathto5Server/RPMS.os/redhat-release-5Server-5.2.0.4.i386.rpm http://10.0.0.1/pathto5Server/RPMS.os/redhat-release-notes-5Server-12.i386.rpm

这里的10.0.0.1是局域网上的一台维护着as4、as5仓(repository)的服务器
然后

apt-get clean all # 清apt缓存
vim /etc/apt/sources.list # 更改apt的安装源为as5的安装仓(repository)

再接着

apt-get update;apt-get check

接着升级rpm*并安装上yum*

apt-get install rpm* rpm\* yum* yum\*

到这里,第一个考验来了,系统抱错:

“srptools: Obsoletes: openib-srptools”

rpm -qa | grep srptools没发现系统装的有srptoolsopenib-srptools
但是在as4的仓里有openib-srptools、as5的仓里有srptools

rpm -ivh http://10.0.0.1/pathto4Server/RPMS.os/openib-srptools-0.0.6-7.i386.rpm http://10.0.0.1/pathto4Server/RPMS.os/openib-1.2-7.i386.rpm http://10.0.0.1/pathto4Server/RPMS.os/libibumad-1.0.5-7.i386.rpm http://10.0.0.1/pathto4Server/RPMS.os/libibcommon-1.0.3-7.i386.rpm

上面这一步其实可能不用,因为后来openib-srptools又给删掉了

rpm -ivh http://10.0.0.1/pathto5Server/RPMS.os/srptools-0.0.4-2.el5.i386.rpm

你要srptools我就给你装srptools

rpm -e openib-srptools

删掉openib-srptools

rpm -e openldap-clients cups-libs openldap elinks ckermit nmap cyrus-sasl-devel pwlib curl neon libwvstreams stunnel pyOpenSSL dhcpv6_client rhnlib wvdial openh323 openldap-devel nss_ldap libuser cyrus-sasl nss_ldap compat-openldap cyrus-sasl-ntlm cyrus-sasl-gssapi cyrus-sasl-plain cyrus-sasl-md5 libuser-devel usermode passwd nfs-utils autofs nfs-utils-lib kbd system-logviewer authconfig-gtk usermode-gtk system-config-network-tui system-config-lvm system-config-packages system-config-language system-config-date system-config-nfs system-config-services system-config-securitylevel system-config-soundcard system-config-rootpassword system-config-keyboard system-config-network redhat-lsb system-config-users system-config-mouse sendmail cyrus-sasl-sql mutt python-ldap apr-util-devel up2date cadaver curl-devel php php-gd php-mysql php-mbstring php-pear python-ldap kdebase samba-common samba-client gnupg evolution-data-server httpd apr-util samba-common samba-client libgnomeprint22-2.8.0-3.i386 ghostscript kdelibs ghostscript tog-pegasus mdadm fetchmail httpd-devel kdemultimedia gnome-panel cups-libs httpd kde-i18n-Chinese kde-i18n-Chinese-Big5 gimp-print iiimf-gnome-im-switcher tog-pegasus-devel ghostscript-fonts httpd-suexec libgnomeprintui22 gtksourceview libgnomecups cups rpm-devel rpm-build redhat-rpm-config bg5ps VFlib2 dmraid

再删掉一大堆妨碍升级rpm*并安装yum*的东东
反正到最后

apt-get install rpm-libs rpm-python rpm yum

成功了
这一步的时候,貌似apt就给删掉了,否则还需要rpm -e apt一下
然后把yum的安装源指向我们自己的仓
再执行升级

yum update

完成后再做一次base安装,因为前面删的东西太多了,怕有的东西是必须的,所以做一次base安装

yum groupinstall base

这个时候会出一个”device-mapper“相关的错误
这是因为系统目前的device-mapper包(as4的)比安装仓(as5)里的device-mapper的版本还要新!
这也就是我前面说为什么升级之前把系统升级成as4的最新版也许还添了麻烦的原因
没办法
先强行升级device-mapper

rpm -Uvh –force http://10.0.0.1/pathto5Server/RPMS.os/device-mapper-1.02.24-1.el5.i386.rpm

最后yum groupinstall base完成后
再装下新kernel(如果没自动装的话)

yum install kernel-PAE kernel-PAE-devel kernel-doc

再用新kernel起起来就ok了

分类: Operation System 标签: , , , , , ,

关于linux的oom-killer

2008年12月8日 没有评论

这些天仔细了解了些关于linux的oom(out of memory)-killer机制的知识
赶紧记下来,否则又忘了:)
32位系统的机器
内存分DMA、LowMem和HighMem三部分
# DMA: 0x00000000 – 0x00999999 (0 – 16 MB)
# LowMem: 0x01000000 – 0x037999999 (16 – 896 MB) – size: 880MB
# HighMem: 0x038000000 –
LowMem区(NORMAL ZONE)一共880M,除非当用Hugemem的kernel的时候4G内存都是LowMem区
系统出oom-killer问题主要是因为LowMem内存太少或者是碎片太多,当系统进程请求不到合适的内存区域的时候
就会调oom-killer
在2.4的kernel下,貌似oom-killer会kill掉最新的进程;而2.6的kernel下,则会kill掉占用内存最多的那个进程,而且如果有共享内存的话,相关的进程都会被kill掉

下面再谈解决方法
最好的解决方法是
1,升级到64位系统,这样的话所有的内存都会被认为是LowMem
2,使用hugemem的kernel,这样的话,最多有4G的内存可以被认为是LowMem
3,as4的话有个参数vm.lower_zone_protection

# echo “250” > /proc/sys/vm/lower_zone_protection
add the following to /etc/sysctl.conf:
vm.lower_zone_protection = 250

又遇oom-killer

2008年12月8日 没有评论

以前在fc3下碰到过一回oom(out of memory)-killer,具体见这里
今天又碰见了
测试在一台服务器(rhel5 update2)上测试某个服务器程序的最大连接数
结果到一定程度服务器进程就会被干掉
上去发现是iptables开着
上去关掉iptables,再重新试
这回当连接数打到15w左右的时候
进程被系统踢出来
看/var/log/message
发现是

kernel: Out of memory: Killed process xxxxx

xxxxx是数字,进程号

果然是传说中的oom-killer干掉的

查了下比较粗暴的解决方法:
1,disable掉oom-killer功能
Turn oom-killer off/on:

# echo “0” > /proc/sys/vm/oom-kill
# echo “1” > /proc/sys/vm/oom-kill

or 修改/etc/sysctl.conf:

vm.oom-kill = 0

2,保护某个进程不被oom-killer干掉

# echo -17 > /proc/[pid]/oom_adj

/proc/[PID]/oom_adj来实现的,其中oom_adj的取值返回是-17~15,当进程的 oom_adj是-17时,系统将不会杀死它,-16到15使得进程的/proc/[PID]/oom_score值呈指数(K * 2 ^ n)形式递增,也就是说他们被杀的可能性呈指数形式递增。另外,开天辟地的第一个进程(进程号为1)init也不在被杀之列,无论它的oom_adj值为多少。