Archive for category Unix
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。
- 注意整个系统的安全策略,账户策略等,相比中间人攻击这样的“高级”黑客行为,破解密码,利用漏洞永远是成本最低的方法。
FreeBSD+apache+PHP+OCI支持Oracle
由于FreeBSD的Port中自带了oracle-client可用,但仅支持i386的平台,故此文仅针对于i386,AMD64无法实现oci的连接库。
首先,确定你已经安装好apache + php,没有安装的可以参考这里或者文学化的这里
安装php5-oci8
cd /usr/ports/database/php5-oci8
make install clean
安装到这里,Php的OCI8库已经安装成功,但需要对oracle-client进行设置,否则无法使用。
将tnsnames.ora拷贝到/usr/local/oracle8-client/network/admin/ 目录下
内容大致如下: Read the rest of this entry »
关于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 »
SSH的x-forwarding
记得N年前写过一篇东西,讲的是SSH的秘钥验证登录。这次就跳出命令行,讲讲X桌面的X-forwarding。
其实*nix下的桌面也是一个网络服务,可以通过SSH来远程执行。如果您使用的是Linux的桌面版,可以通过ssh的-X 或 -Y参数:
Oracle+Sun=?
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以上还能迅速响应。
踩到雷
公司的邮件服务器升级了一下perl,从5.8.8到5.8.9。只为更好的支持更新版本的webmail程序。按理说作为FreeBSD系统,升级下perl不是什么困难的事情,可真正的问题才刚刚开始。
首先是要伴随perl升级一系列的模块,这似乎也不是难事。然后是执行perl-after-upgrade。一切似乎很顺利。随意习惯性的top了一下,发觉负载已经高达60%以上,而且是邮件系统的MailScanner的进程奇高。考虑到MailScanner引用了perl,很明显的需要restart一下。这时候问题来了。
restart之后,邮件不能正常接收,检查原因,发觉邮件在MailScanner中不停的check。赶紧检查日志,很明显的报错:
MailScanner[66402]: Could not use Custom Function code /usr/local/lib/MailScanner/MailScanner/CustomFunctions/GenericSpamScanner.pm, it could not be “require”d. Make sure the last line of the file says “1
调用万能的google,关键字perl5.8.9 MailScanner,发觉通篇都是与我一样的报错,最新的记录似乎也没多远。貌似是我幸运的踩到了雷。
临时处理方法其实也是非常简单的——退回到perl5.8.8就OK。


最近评论