一个CUPS系统小问题的解决经历

applewolf

这几天在回忆以前做包经历,想起了一个曾经经历过的小插曲.

那些日子,我在试图把SLAX做成一个可以用于普通办公室应用的应用平台,在做CUPS打印方面的配置,可以说,一切还是蛮顺利的,写了几个鼠标点点就可以启动的脚本后,一测试,全OK,于是把成功做成的包从6.2.0平台转移到了6.1.2平台上,起先还没注意到有什么问题,直到有一天我想试试从SLAX下打印一份客户的合同时,才发现,居然不能输出到打印机了.我们办公室的打印机是通过网络打印的,打印机挂在DD-WRT的路由器上的,通过TCP/IP 的9100端口打印.

非常奇怪,在6.2.0上试用,又一切正常,于是又开始了漫长的排错过程,一路跟踪打印过程,分析日志,重新配置,甚至是重新在SLAX 6.1.2平台上编译,都是同样的错误.......

非常郁闷, Google 了一下,似乎有不少人遇到这种情况,但差不多都是选择了重装系统来解决问题.狠劲儿上来了,我倒不信这个邪了,于是从头到底又过滤了一遍,非常失望,在官网发贴问也无果.....

就在我打算放弃6.1.2平台时,我突然在想,会不会是别的包与之冲突呢? 于是又重新开始了整个系统的拆包分析,一个一个包过滤过来,当全部的包都过滤完后,问题依然.....

在不经意间,我发现有一个被拆开的包的usr目录权限好象与别的包不太一样,于是,想,会不会是这个包usr 权限的问题,想测试一下,在加载着这个包的情况下重启一次系统,发现usr目录权限是正确的啊,没有问题啊,但是解包后那个包的usr目录权限不对,于试我尝试着把那个包usr目录权限修正了一下,重新打包,再启动系统,天啊,一切都正常了......

一个包的权限问题,导致我拆了整个系统......无语.

下面说明一下我当时的情况:

我解开那个问题包后.无意间发现,它的 usr 目录权限居然是:
drwx------
但正常的usr 目录权限应该是
drwxr-xr-x
也就是说,其它用户和组都有读取、执行的权限,root 拥有读、写、执行权限

于是我在加载着这个问题包的情况下重启系统，检查了一下使用中的 usr 目录权限，居然是正确的
drwxr-xr-x
也就是说，在问题包后加载的包的 usr 权限虽然正确，但是这个包的权限依然影响了 cups 系统的正常使用，用chmod -R 修正问题包 usr 目录权限为 drwxr-xr-x 后，再启动系统，cups 正常了。。

其实写这篇贴子的目的是为了时时能提醒自己，在做包时一定要仔细，尽量对每个包进行几次验证，以免因为这种小问题导致不必要的大动作，浪费时间，浪费精力。