日归档:2013 年 11 月 9 日

解除部分exadata上的“强安全策略”

在安装Exadata时,执行onecommand的后面几步ResecureMachine相关的内容后,安全性会得到增强,我们戏称为“强安全步骤”,不同的onecommand版本的step稍有差别,但是可以从deploy脚步的执行步骤的名称中识别出来,例如onecommand p14210449 (对应image 11.2.3.1.1)的如下(其中setp24~setp26): 在onecommand p16383189(对应 image 11.2.3.2.0,image 11.2.3.2.1的步骤跟这个一样的)中是如下步骤,其中step25~step28是“强安全”: 在执行了上述步骤后,一些客户使用一段时间后对于其中的“强安全”感觉很不方便,希望我们修改其中的部分限制,比如90天必须修改口令等等,下面就类似问题给出解决方案。 本文的方法来自于内部exadata的一个文档,且在多个客户都已经实施过了: 1, 解除口令限制和复杂度: 使用root用户修改/etc/pam.d/system-auth,这是一个password的的入口文件(老一点的linux系统一般用/etc/pam.d/passwd),将其中的”min=disabled,disabled,16,12,8″ ,使用这个规则建立的口令很难被破解,修改为”min=1,1,1,1,1″,大大降低了口令的复杂程度(容易被破解,例如“oracle”,或者exadata上的缺省的welcome等等,都是常用词汇。。。) 然后重置root口令即可(exadata上大部分缺省口令是welcome) 2, 解除90修改口令的限制: 执行下面的命令修改用户口令修改策略: 当然,你需要在所有节点依次执行,exadata上的dcli可以很方便的完成: 然后使用上述用户登录的缺省口令就可以登录了(缺省口令都是welcome) 3, 重新配置各个节点的SSH信任关系(因为执行了ResecureMachine以后,SSH信任关系操作就不可以了): 也可以参考我之前的一篇blog(其中的脚本在11.2.0.1的除windows平台外的任何一个安装包中都可以找到): 使用Oracle安装包的ssh配置机器互信 注意: 如果有问题可以参考bug 12389246 4, 解除SSH连接超时的限制: 顺便多说一下,由于某些原因用户可能会出现密码尝试次数过多账号被锁定的问题,具体的设置在/etc/pam.d/system-auth文件,例如,exadata上的: 清除某个用户的登陆失败次数,让改用户可以重新登陆的命令: pam_tally2 -r -u username 例如, 清除 oracle用户的失败登录次数:pam_tally2 -r … 继续阅读

发表在 FAQ, 日常运维 | 标签为 | 留下评论

一个老系统的老问题:ORA-01031: insufficient privileges

今天打算整合一下所有的vm(除了12c),把他们都放到一个vm中,结果发现遇到郁闷问题: –第一反应是口令文件有问题,于是检查,发现果然缺少口令文件: –还是不行,是否因为大小写的关系(因为之前的那个vm已经迁移到活动硬盘了,懒得打开查看SID了),因此修改为大写试试看: –使用密码文件的认证方式测试本地登录是可以的: –怀疑是sqlnet.ora的设置有问题,结果居然没有,这个vm是7,8年前的,不知道什么原因,居然没有这个文件,创建一个吧: –这里居然冒出来ORACLE_HOME设置不对,郁闷了。。。。。。 –重新执行环境设置脚本: –这是,怀疑是oracle用户本身的问题,于是检查oracle用户的属组: –经过小伙伴的提醒,发现这个VM居然使用了破烂SELinux,sigh。。。。。 –SELinux系统比起通常的Linux系统来,安全性能要高的多,它通过对于用户,进程权限的最小化,即使受到攻击,进程或者用户权限被夺去,也不会对整个系统造成重大影响。 –但是往往有些应用的使用也会受到限制,比如有时候tar一个大目录的时候可能会失败,有时候ftp东西的时候有问题,等等 –其实一般ORACLE的文档上也是明确说明要关闭SELinux的,例如: –5.11 Error While Loading Shared Library When SELinux is Enabled on Red Hat Enterprise Linux 5 –SQL*Plus and Oracle Call Interface (OCI) program calls fail when selinux is … 继续阅读

发表在 FAQ, ORA-XXXXX | 留下评论