OurApache » Apache解错方案 http://ourapache.com 我们致力于一个Apache知识的分享网站 Tue, 13 Apr 2010 05:18:24 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 解决linux下安装ssl后，apache重启时需要密码 http://ourapache.com/archives/326 http://ourapache.com/archives/326#comments Tue, 13 Apr 2010 05:18:24 +0000 OurApache http://www.ourapache.com/?p=326 解决linux下安装ssl后，apache重启时需要密码的问题。

在帮客户购买的vps上面安装完SSL以后，每次启动apache时都需要输入密码，觉得维护起来非常的麻烦。

客户的vps是ubuntu Sever，其他linux服务器找到相关文件修改

编辑：.conf ,

ubuntu下面的目录：

/etc/apache2/mods-available/ssl.conf

修改ssl.conf

# SSLPassPhraseDialog builtin

SSLPassPhraseDialog exec:/ect/apache2/key.sh

编辑：/ect/apache2/key.sh

!/bin/bash

echo ‘your pass phrase’

注意key.sh的权限755

重启服务器

问题解决

无相关文章，以下随机显示

标签：, ,
]]> http://ourapache.com/archives/326/feed 0 在64位机器上关于Apache 2.2.3版的编译问题 http://ourapache.com/archives/142 http://ourapache.com/archives/142#comments Tue, 17 Feb 2009 04:39:06 +0000 OurApache http://www.ourapache.com/?p=142 2.2.3版的apache在64位机器上进行编译会出现如下错误：

usr/lib/libexpat.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libaprutil-1.la] 错误 1
make[3]: Leaving directory `/root/tar/httpd-2.2.3/srclib/apr-util’
make[2]: *** [all-recursive] 错误 1
make[2]: Leaving directory `/root/tar/httpd-2.2.3/srclib/apr-util’
make[1]: *** [all-recursive] 错误 1
make[1]: Leaving directory `/root/tar/httpd-2.2.3/srclib’
make: *** [all-recursive] 错误 1
 

错误的解决方法可以参考邮件：http://www.mail-archive.com/bugs@httpd.apache.org/msg24675.html

具体的做法如下：
1 setenv LDFLAGS “-L/usr/lib64 -L/lib64″    [用于csh，其他shell请用export命令]
2 ./configure 时加入 –libdir=/usr/lib64 参数
3 修改./srclib/apr-util/下的Makefile 改 APRUTIL_LIBS 的值中的”/usr/lib/libexpat.la” 为 “/usr/lib64/libexpat.la”
然后进行编译。

相关文章

标签：, ,
]]> http://ourapache.com/archives/142/feed 0 让apache支持自定义404页面错误 http://ourapache.com/archives/136 http://ourapache.com/archives/136#comments Thu, 12 Feb 2009 08:09:48 +0000 OurApache http://www.ourapache.com/?p=136 在rewrite开启的情况下，当URL发起请求的页面在服务器端不存在的时候，返回http status code ==400;
而通常文件没有找到应该返回404状态码，查询N久无解中，关闭rewrite一切正常

在VirtualHost内部使用 ErrorDocument /notfound.  当服务器响应为404的时候会自动跳转到notfound.
为了适应多种浏览器的不同 /notfound.php最好使用绝对的HTTP开头，如：http://blog.daxi8.cn/notfound.php

可以使用 .htaccess文件关闭 RewriteEngine Off 来关闭在此目录的rewrite模块

相关文章

标签：, ,
]]> http://ourapache.com/archives/136/feed 0 apache core段的DocumentRoot与访问权限 http://ourapache.com/archives/132 http://ourapache.com/archives/132#comments Thu, 12 Feb 2009 07:00:18 +0000 OurApache http://www.ourapache.com/?p=132 Tips:

设置Apache的虚拟主机时的路径权限要仔细

虚拟主机段配置如下：

NameVirtualHost *:80
<VirtualHost *:80> 
        ServerAdmin zhao@sst.cn 
        /somewhere/ww1 
        ServerName ww1.sst.cn 
        ErrorLog logs/ww1.sst.cn-error_log 
        CustomLog logs/ww1.sst.cn-access_log common
</VirtualHost>
<VirtualHost *:80> 
        ServerName ww2.sst.cn 
        DocumentRoot /somewhere/ww2
</VirtualHost>

当apache core段的DocumentRoot 值设为/somewhere/ww1时，

访问ww1.sst.cn

通过

访问ww2.sst.cn

Forbiddden

当apache core段的DocumentRoot 值设为/somewhere时，

访问ww1.sst.cn

通过

访问ww2.sst.cn

通过

  分析下来禁止访问产生的原因，是httpd.conf中对相应Directory段没有增加定义，如上例，如果核心DocumentRoot（/somewhere/ww1）不是接下来定义的虚拟主机中的DocumentRoot（/somewhere/ww2）的父目录，则需要增加定义虚拟主机自有的DocumentRoot（/somewhere/ww2）其相应的Directory定义：

<Directory /somewhere/ww2>

    Options FollowSymLinks

    AllowOverride None

</Directory>

自己提醒自己千万要仔细，吃了两次亏，还是忘记。

无相关文章，以下随机显示

标签：, ,
]]> http://ourapache.com/archives/132/feed 0 apache 无法启动故障排查 http://ourapache.com/archives/121 http://ourapache.com/archives/121#comments Tue, 10 Feb 2009 07:15:34 +0000 OurApache http://www.ourapache.com/?p=121 今天在F5上逛，发现某个ip下面的机器的80和443端口down了。
于是手动重启，结果发现apachectl start,可以正常启动，apachectl startssl却不行
查看log
[Wed Apr 16 08:54:52 2008] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten — Unclean shutdown of previous Apache run?
[Fri Jun 13 11:59:24 2008] [alert] httpd: Could not determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName
semget: 设备上没有空间
网上查了半天也无解。试图删除/usr/local/apache/logs/httpd.pid再重启也不行。
问同事才知道
使用ipcs查看系统的信号量，发现是信号量sem已经满了，所以导致startssl无法启动。
据说是如果apache没有正常Stop掉的话，它的信号量是不会自动清除的，导致其一直滞留在内存中
于是，用以下命令清除sem信号量后，apache就可以正常启动了：
for i in `ipcs  | grep nobody | awk ‘{print $2}’`; do ipcrm -s $i; done
看来，以后我们需要慎用killall -9 httpd，尽量使apache能正常的stop
[root@l_192_168_131_164 log]# ipcs
—— Shared Memory Segments ——–
key        shmid      owner      perms      bytes      nattch     status      
0×00000000 7143424    root      600        184324     74         dest          
—— Semaphore Arrays ——–
key        semid      owner      perms      nsems      
0×00000000 0          nobody    600        1          
0×00000000 32769      nobody    600        1          
0×00000000 65538      nobody    600        1          
。。。。。。。。。
。。。。。。。。。
0×00000000 98307      nobody    600        1          
—— Message Queues ——–
key        msqid      owner      perms      used-bytes   messages  

可以看到很多
清除了就可以了
for i in `ipcs  | grep nobody | awk ‘{print $2}’`; do ipcrm -s $i; done

然后再查看

[root@l_192_168_132_089 /root]# ipcs
—— Shared Memory Segments ——–
key        shmid      owner      perms      bytes      nattch     status      
0×00000000 8552448    root      600        184324     74         dest          
—— Semaphore Arrays ——–
key        semid      owner      perms      nsems      
0×00000000 8486912    nobody    600        1          
—— Message Queues ——–
key        msqid      owner      perms      used-bytes   messages  

没有那么多了。

再重新启动apache，这次正常启动了
另外一个问题，就是日志是用中文输出的，对应的错误提示在网上无法搜到，而对应的英文

semget: 设备上没有空间
semget: No space left on device
在google上很容易找到结果。看来以后要把服务器的默认语言设置为英文才行。
 
#export LC_ALL=en_US
#locale
 

无相关文章，以下随机显示

标签：, ,
]]> http://ourapache.com/archives/121/feed 0 重大漏洞, 让Apache上传不安全-php.rar http://ourapache.com/archives/19 http://ourapache.com/archives/19#comments Mon, 05 Jan 2009 12:57:09 +0000 OurApache http://www.ourapache.com/?p=19 一般的网站都会开放rar附件上传,并可能会保留原来文件名称,这从而可能导致一个很严重的问题,xxx..rar文件会被Apache当作php文件来执行, 造成极大的安全隐患 .

如何测试? 将你的某个php程序文件后缀名修改成  xxx.php. , 这时测试一下, 还是按照PHP文件解析执行,Apache并不会认为这是一个rar文件, 这是为什么呢?

原来,每遇到一种后双重后缀名(如xxx.php.rar)的文件,Apache都会去conf/mime.types 文件中检查最后一个后缀, 如果最后一个后缀并没有在mime.types文件中定义, 则使用前一个后缀来解释 , 因为在默认情况下,rar并未在mime.types中定义, 故Apache会使用php后缀来解释文件, 这就是漏洞的原因所在.

由此类推,如果使用xxx.jsp.ppp.rar 则会认为是jsp文件, 如果修改成xxx.shtml.rar ,则会识别成shtml文件.

a.php.c.d.e.rar 也是会被当成PHP文件解释的!
想想,不知道有多少网站存在这个问题?

那么针对网络管理员,如何杜绝这个隐患 ?
1.修改mime.types文件,在最后面加一条:

application/rar rar

然后重新启动Apache,即可.

针对WEB管理员及WEB程序开发者,如何更安全?
1.只允许上传指定后缀名的文件,当然,要禁止掉rar格式文件上传.(但这条往往行不通,一般的网站都需要上传rar文件)
2.对上传后的文件进行强制重命名, 强制使用最后一个扩展名,如原始文件名为xxx.php.rar ,上传后强制重命名为 20080912.rar即可避免这个隐患.

早期版本的phpcms 2007, discuz, ecshop都存在这个漏洞,  或许你的网站被挂马,就是因此引起.

 

 

上面的文章是转的，我测试了一下,还真这样,不过修改mime.types是没有用的.

需要在http.conf中加入下面这些内容

AddType application/rar .rar
AddType application/x-compressed .rar
AddType application/x-rar .rar
AddType application/x-rar-compressed .rar
AddType application/x-rar-compressed; application/x-compressed .rar
AddType compressed/rar; application/x-rar-compressed .rar

 

这样就不会出问题了，测试过了，加我上面这些是没有问题的。

相关文章

标签：, ,
]]> http://ourapache.com/archives/19/feed 0