Posts Tagged Unix
通过motd信息简化巡检操作
作为一个Unix系统的管理员，手工巡检几乎成了工作中一个重要的部分。这里不放使用Linux的motd通告信息实现简单的信息通告，至少能省去了不少手工命令的时间。
motd即Message Of ToDay，每天的信息。大部分的固定文本信息放置在/etc/motd下，如果没有你可以直接创建一个，然后修改其中的内容制作一个主机登录Banner以便于区分多台主机。对于Ubuntu来说，特别是启用了server中“landscope管理系统”后，这里没有效果，你需要修改的文件为/etc/motd.tail。
一个怪异的Cron问题
一个朋友向我咨询他遇到的一个问题。
Centos的操作系统，自然是主流应用的WWW。近期无缘无故的Cron失效，所有的任务都无法执行。多次重启主机，重启Cron服务均是如此。
起先我由于没有拿到控制台，怀疑是Cron经典的环境变量问题，修改了半天也是白忙。总算此兄开恩，将root的权限给了我。:)
python multiprocessing的问题
multiprocessing的是Python2.6中新加入的模块，旨在用类似threading调用tread(线程)的方式使用process(进程)。
服务器中经常需要对大规模的数据进行压缩，传统使用单进程操作不足以体现8核CPU并发的威力。于是写了一个脚本用于多进程压缩。然而在windows的主机上进行调试，全都是死循环，以至于机器都无法进行响应。导入Linux主机，测试却通过。对脚本进行了精简如下：
再谈谈 Oracle+Sun=?
上次写过几篇东西，关于Oracle收购Sun的。Oracle+Sun=? , Sun的身前身后事。
如今尘埃落定，www.sun.com 也已经被重定向到了www.oracle.com 。至少局外人看来，两家公司已经合并，而且至少不是失败的。
也就是在今天，得知oracle放出消息：今后Solaris不再免费提供，下载版本只提供90天的试用。如果使用，请买授权！
从个人角度上来说，我当然希望是提前一天庆祝了明天的节日。但事实上这并非是空穴来风。
Solaris连锁故障
公司有一台服务器，属于经常被冷落的那种。SunV245 + solaris 10 + Oracle 10G 。自从装好机之后uptime至少有2年了。
且说这天需要重启，重启后无法通过ssh连接，通过串口终端连上之后发觉由于之前习惯于ssh key登录，一直没有root密码。郁闷中。
用SSH Tunnel穿越防火墙
这次接上篇。
很多企业对互联网的访问进行了限制，如何突破防火墙的限制成了一个问题。本文就是利用了SSH tunnel搭建了socket5代理。
首先，申请一个外网的ssh帐户，个人建议使用http://www.unix-center.net/提供的免费资源，该网站还提供多种平台主机可供测试之用，非常不错！当然，如果可以使用密钥方式登录那就完美了。
用ssh tunnel打造安全邮件系统
近期，甚至于连Google这样的企业也感觉到了邮件系统的安全问题。这里采用了相对实现成本较低的方式，通过ssh的tunnel达到邮件在传输的过程中不会受到中间人攻击造成数据泄露。
故名思义，tunnel就是在邮件服务器和企业防火墙之后设置一条逻辑上的隧道。这条隧道一方面为了数据安全，另一方面，由于ssh的压缩功能也能在一定程度上减少邮件这类纯文本传输的网络需求。
先决条件：
- Unix like的邮件系统，并安装了ssh-server，本例中假定邮件服务器ip为1.2.3.4
- 企业路由器和内网：路由最好有vpn和防火墙功能。
- 内网的 一台主机，配置不必太高（我用了虚拟机，64M内存已经足够近百人使用），安装有ssh-client，如果是win主机，推荐使用putty的安装版本。经过测试，个人觉得FreeBSD下的性能较好。考虑到安全，这台主机尽量不要安装远程控制台并尽可能上锁。本例假定ip 192.168.1.1。
- 注意整个系统的安全策略，账户策略等，相比中间人攻击这样的“高级”黑客行为，破解密码，利用漏洞永远是成本最低的方法。
关于vmstat
上次谈了load average ，这是一个反应CPU资源利用状况的命令。现实情况下，特别是现在CPU疯狂便宜的时代，对于一个服务器往往不见得是CPU吃紧，这次就来讲讲相对反应整体状况的vmstat命令。
以本人的Freebsd为例，其余的系统类似，直接套用就Ok了。
WWW# vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id
0 0 0 738M 108M 957 30 38 0 1226 72 0 0 1782 983 922 2 6 92 Read the rest of this entry »
Sun的身前身后事
最近业界的有个传闻很引人注意，那就是IBM正在与Sun进行收购谈判。最终结果如何都是大家期待的。一代枭雄的Sun再也支撑不住，似乎大厦将倾了……
当大家都在关注Sparc平台，Java中间件，Solaris操作系统以及一大堆应用的何去何从时，业界的另一个比较有趣的话题逐渐的浮出水面–作为Java下的应用，同时又是IBM竞争对手的Oracle和SAP是否还会继续支持Java？选择继续无疑于与虎谋皮；选择放弃Java，拜托，这么多的客户岂不是要倒戈？
关于 load average
很多人都知道uptime命令会得到如下的返回：
12:00:59 up 20:24, 1 user, load average: 0.49, 1.40, 1.61
其中的load average根的3个数字，分别表示系统在1分钟，5分钟和15分钟的平均负载情况。这个数字是系统每5秒钟会自动检测一下活跃的进程数量（即top命令看到的n running），然后得出结果。具体感兴趣的话可以研究下Linux内核中include/linux/sched.h， kernel/timer.c，fs/proc/proc_misc.c
所谓活跃的进程，需要满足：
- 没有被终止或者正在调用wait。
- 不是正在等待I/O操作。
很多网上说这个数字除上CPU的数量如果得到的结果大于5就说明系统在超负荷运转。对于这个结论本人持保留意见。
- 对于双核或者多核的CPU，如果按照1个CPU来计算，那么明显的状况就是对于多核心的不公。如果按照多个CPU来计算，那又是对于多路CPU，甚至是独享内存总线多CPU的不公。对于基于HT技术的“假多核”更是如此。
- 对于不同平台的CPU而言，目前公认的是X86架构“不耐压”，特别在于高并发的情况下。本人明显觉得SPARC的架构相比X86在压缩同一个文件的时间更长；但是同时进行多个压缩的时候Sparc的平台占有绝对优势。
- 与IO关系不够紧密，很多情况下，最容易制约系统的是IO，特别是现在正处在“运算不值钱，储存值钱”的时代。
- 超负荷的界定：有的系统，在1.5的情况下已经能够感到明显的延时；同样有的系统在10以上还能迅速响应。
广告链接
近期评论