Browsed by
标签:apache

Debian7升级到Debian8

Debian7升级到Debian8

最近Debian发布了Debian8.1版本,可以比较正式地商用了,因此打算将一套生产环境的debian7升级到debian8。

Debian不像Ubuntu,后者使用上确实方便,基本上一键就可以搞定。不过Debian也不麻烦,事实证明也很简单。

step1:关闭已经运行的一些服务器程序,例如apache,mysql等。

step2:更新当前版本,也就是sudo apt-get update以及sudo apt-get upgrade即可。

step3:修改/etc/apt/sources.list文件,将wheezy替换成jessie,例如下面就是目前生产环境上的配置:

deb http://mirrors.aliyun.com/debian/ jessie main non-free contrib
deb http://mirrors.aliyun.com/debian/ jessie-proposed-updates main non-free contrib
deb-src http://mirrors.aliyun.com/debian/ jessie main non-free contrib
deb-src http://mirrors.aliyun.com/debian/ jessie-proposed-updates main non-free contrib

deb http://mirrors.aliyun.com/debian-security/ jessie/updates main non-free contrib
deb-src http://mirrors.aliyun.com/debian-security/ jessie/updates main non-free contrib

deb http://http.us.debian.org/debian/ jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free

需要注意的是以下几点:

(1)尽量配置国内的镜像源。debian官方源在国内大部分区域都比较慢,采用国内源能节省大量时间。

(2)推荐使用阿里镜像源。阿里巴巴虽然是个逗比公司,不过阿里镜像还是做得相当不错,速度快、网络稳定,我们一直都用它。

step4:更新系统。依次执行下述命令即可:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

执行过程中,涉及到一些软件更新后配置文件有改变,默认采用原有配置。

对apache的影响

apache2升级后,配置文件有改动,导致出现“403 forbidden”的情况。问题原因是apache2的部分配置参数取消了,需要用新的参数替代。修改/etc/apache2/sites-enabled/000-default(-ssl)文件:

 Order allow,deny
 allow from all

修改为:

require all granted
Apache自动输入密钥文件密码

Apache自动输入密钥文件密码

从startSSL申请了证书并成功加载到apache,这些都是通用步骤,具体可以直接参考startSSL的说明文档:http://www.startssl.com/?app=21

然而由于密钥文件是采用访问密码保护,因此重启apache时,读取密钥文件会要求手工输入密码,例如以下提示信息:

Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Enter pass phrase:

这样非常不方便,因此需要将密钥的访问密码告诉apache,并自动输入该密码。

以下步骤都是以root身份进行,系统为Debian 7。

创建shell文件:vi /etc/ssl/apache_pass.sh,并输入以下内容,用于输出访问密码:

#!/bin/sh
echo "1234" <-- 这个是密钥文件的访问密码

出于安全的考虑,将这个文件设置为可执行,并且只能由root访问:

chmod 400 apache_pass.sh
chmod +x apache_pass.sh

接下来就是修改/etc/apache2/mods-available/ssl.conf文件,将SSLPassPhraseDialog由默认的builtin修改为以下值(其实就是执行上述shell文件):

SSLPassPhraseDialog exec:/etc/ssl/apache_pass.sh

完成上述步骤后,重启apache2,将自动输入密钥文件的访问密码,不再需要手工操作。

嵌入式HTTP服务器设计

嵌入式HTTP服务器设计

定义

所谓“嵌入式HTTP服务器”包含这么几个意思:

(1)TA首先是微型的,不能太庞大。往往成为其他应用程序的一个组成部分,提供HTTP接口(包括RESTful接口)或者HTTP服务(例如WWW服务)。

(2)功能有欠缺,不是全功能服务器。比如,肯定不能像Apache、Nginx这样提供全面的HTTP支持。只能提供一个最小化的、需要定制化的功能集。

现状

在miniSIPServer中,我们以前采用mongoose这个轻量级http服务器来提供web接口。mongoose基本符合要求,但也很难让人感觉满意。主要存在以下一些问题:

(1)代码凌乱。是的,这个问题比较严重。实际上我们花了不少时间来清理TA的代码,但是效果不太好。TA的实现方式有不少问题,各逻辑层次之间解耦不充分,因此在编写应用层代码(尤其是ajax接口代码)时,不得不大量重复使用一些要求的宏定义,造成代码繁杂紊乱。

(2)定位不清晰。如果单纯定位为嵌入式服务器,可能mongoose的发展会好很多。但是我们看到,ta的代码之所以凌乱,有一个重要原因就在于:试图成为一个全功能集的http服务器。大量功能集堆积在一起,又没有处理好模块关系,结果就和意大利面一样绞成一团。

(3)原维护者似乎已经放弃这个产品。从代码库看,更新不是很频繁,缺乏关注。后续一些问题看不到解决的希望。在具体实现时,不得不小心翼翼地规避一些问题。

(4)IPv6支持不足,尤其不能适应IPv4和IPv6混合组网的情况。

新版的miniSIPServer设计中彻底抛开mongoose代码,重新实现自己的嵌入式HTTP服务。从效果看很不错:不考虑服务器自身的代码,仅仅看应用层的代码,就从原来近7K行,直接砍到了3K行。

新设计

当然,设计一个Apache或者Nginx是很复杂而且艰难的事,但设计一个嵌入式HTTP服务器的确很容易。简单来讲只有以下几个步骤而已:(1)打开TCP端口;(2)接受客户端连接;(3)收客户端的HTTP请求;(4)返回HTTP响应消息;(5)关闭TCP连接。

TCP网络编程是通用的,windows平台可以用IOCP,linux平台可以用epoll等。MSS作为SIP服务器,早就封装好了底层的通信库,因此仅仅需要关注步骤(3)和(4),读一读HTTP协议,根据HTTP的要求进行相应处理即可。

HTTP协议

最新的HTTP协议已经定义到HTTP/2.0,但现网大部分都还是HTTP/1.1,另外考虑到2.0主要是在SPDY以及加密等方面的修改,而这些对嵌入式HTTP设计而言不是很必要的,因此支持HTTP/1.1就好。

原HTTP协议定义在RFC2616,目前已经修改为多个RFC文档共同定义:RFC7230~RFC7235。实际上我们只需要关注前三个RFC文档:

  • RFC7230 “Message Syntax and Routing”。这是最基础的协议。定义了HTTP的基本交互模式,基本消息结构等。
  • RFC7231 “Semantics and Content”,定义了HTTP消息语法,包括RequestLine以及各Header等定义。SIP的语法就是基于这类定义。
  • RFC7232 “Conditional Requests”。主要是考虑一些有条件的请求及响应。最普遍的就是重复请求网页时,可以判断是否需要每次都返回内容,也可以要求客户端直接使用cache内容,节省网络流量,节约处理能力。

HTTP请求

与SIP的startLine是完全一致的,由method、requestTarget以及HTTP协议号三部分组成。method有多种,例如GET、POST、PUT、DELETE等。我们仅仅支持GET即可。

在请求消息的各项Header(头域)中,我们仅关心以下两个Header:

  • “Cookie”头域。用来传递Cookie参数。在web管理系统中,我们需要设置cookie确保用户登录系统后能继续使用各项管理界面。而没有cookie或者设置不正确的用户,将被视为非法用户。
  • “If-Modified-Since”头域。这是个非常有必要的域。一旦服务器发现客户端请求的内容没有变更,可以直接返回304响应,要求客户端直接用以前的结果就好。

HTTP响应

响应消息和SIP一样,也是定义1xx~6xx。实际设计中我们仅需要关心1xx、2xx、3xx以及4xx即可。响应消息没什么好说的,无非就是各种ContentType等,读取文件,通过TCP连接发给客户端即可。

与SIP比较而言,HTTP最大的特点是无状态。一个“请求-响应”即构成了一个完整的HTTP动作过程。因此HTTP可以利用LVS、HAProxy等技术支持大规模并发。而SIP受限于对话状态,多个“请求-响应”之间是可以关联的(例如INVITE和reINVITE),只能通过ALG、Proxy等呼叫分发来支持大规模的应用。

HTTP路由

具体内部实现时,采用action模式,根据HTTP请求的URL进行索引,用URL对应action即可。服务器本身可以设置一些过滤接口,也可以向应用层提供action接口,由应用层决定各URL对应的处理过程。这点在处理AJAX请求或者提供RESTful接口时尤其有用。

其他

我们的设计目前只支持HTTP。对于HTTPS,理论上而言也不是很困难,无非就是加载CA文件,在TCP建立时进行TLS/SSL鉴权,后续处理与HTTP没有差别。

另外就是安全防护问题,例如防DDOS攻击等,我们没有考虑这方面。虽然应用层可以利用过滤接口或者action接口进行一定程度的防护,但主要的保护依赖于边界网关,毕竟嵌入式HTTP服务器只是用来方便设备管理和配置,不是提供通用HTTP服务的。

SSLv3漏洞

SSLv3漏洞

这次是Google发现的一个漏洞,而且又是一个很严重的漏洞。现在暂时还没有补丁解决,但是可以关闭apache的SSLv3来屏蔽这个漏洞。修改方法如下(Debian7.x环境):

修改/etc/apache2/mods-enabled/ssl.conf文件, 找到SSLProtocol所在行,去掉SSLv3即可

SSLProtocol all -SSLv2 -SSLv3

最后当然需要重新启动apache。

Apache无法执行php的问题

Apache无法执行php的问题

最近将开发环境从Kubuntu 12.04升级到13.04,整个过程基本顺利。然而在使用过程中,逐渐发现一些有问题的地方,升级实际上导致了一些问题。例如Apache出现的问题。

升级后,Apache运行php脚本时全部失败,在log中可以看到以下一些类似的信息:

SoftException in Application.cpp ...
premature end of script headers...

解决方法也比较简单,将libapache2-mod-suphp模块删除后重新安装即可,没有去深究其中的具体原因。从中也可以看出:linux各版本目前作得都比较不错了,可是还是总有一些小问题会时不时出现并困扰你,让你去折腾,这可能也就是为什么linux始终无法进入主流消费者领域的原因吧。

 

在apache中区分端口配置多个网站

在apache中区分端口配置多个网站

以下配置在kubuntu12.04版本中验证通过。假设有两个网站,分别配置在80端口以及81端口。

step1:修改/etc/apache2/ports.conf,增加以下内容:

NameVirtualHost *:81
Listen 81

step2:修改/etc/apache2/sites-available/default文件,增加以下内容:

<VirtualHost *:81>
    ServerAdmin webmaster@localhost

    DocumentRoot /home/yxh/work/mss_web
    <Directory />
        Options FollowSymLinks
        AllowOverride all
    </Directory>
    <Directory /home/yxh/work/mss_web/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride all
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /home/yxh/work/mss_web/cgi-bin/
    <Directory "/home/yxh/work/mss_web/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

最后,重新启动apache2即可:

sudo service apache2 restart
Kubuntu12.04中apache2配置上的一些变化

Kubuntu12.04中apache2配置上的一些变化

在以前的版本中,如果需要配置HTTPS访问方式, 只需要修改/etc/apache2/sites-available/default-ssl文件即可。

可是在新版本中,如果仅仅是修改这个问题,还是无法以https方式访问apache2. 在apache的error.log中,会出现以下错误提示:

Invalid method in request \x16\x03\x01

需要多做几个配置来解决:

在/etc/apache2/mods-enabled目录下,添加以下链接:

sudo ln -sf /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf
sudo ln -sf /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/ssl.load

在/etc/apache2/sites-enabled目录下,添加以下链接:

sudo ln -sf /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl

然后重启apache2即可:

sudo service apache2 restart

对比检查Kubuntu10.04以及11.10中的配置,以前的版本中都已经自行创建了上述这些链接,不知道为什么在新版本中没有这么做。

linux系统对比商业操作系统,一个非常大的不足就是兼容性考虑不足,实在是太随意了。兼容性不仅仅是二进制运行程序的兼容性,也包括库,配置,头文件等等。像上面这样的配置上的变化,说大也不大,可是如果是生产环境上的系统进行升级,就不知道有多少这样的“小改动”了。

Chrome为什么会快些?

Chrome为什么会快些?

常见的理由是有一个强大的V8 javascript引擎。而最近在研究Ajax时,无意发现Chrome和IE在处理HTTP基础协议时,实际上也存在很大的差异,这些差异可以导致即使处理HTML/JS文件时,两者的处理速度也会很不一样。

测试时采用Apache 2.2.20(Ubuntu)作HTTP服务器。

在Apache中设置Cache-Control,指定no-cache,我们来看看Chrome和IE会怎么处理。

Chrome发送GET请求,包含If-None-Match以及If-Modified-Since等重要参数。Apache比较对应的ETag以及Last-Modified,发现文件没有改变,因此仅返回”304 Not Modified”。可见,Chrome直接使用了自己Cache的内容,并没有理会no-cache指示。

而IE呢?IE理会了no-cache指示,因此在GET请求中,老老实实地抹掉了If-None-Match以及If-Modified-Since参数,Apache返回200OK并重新携带请求的内容,IE重新处理返回的内容。

从对no-cache参数的字面理解看,IE的处理是正确的,而Chrome显得比较奸诈。

对于某些情况,我们确实需要强制浏览器端重新获取内容(尤其是对javascript文件),此时在Apache中不仅要设置no-cache,还必须设置no-store。

同时设置no-cache和no-store后,IE/Chrome都会向Apache重新请求内容,并刷新本地内容。

Apache report error: [error] (13)Permission denied: exec of ‘/cgi-bin/signup.php’ failed

Apache report error: [error] (13)Permission denied: exec of ‘/cgi-bin/signup.php’ failed

在桌面版本Ubuntu上,通过Apache2测试PHP程序时,会遇到几个问题:

(1)Apache2把PHP文件当成普通文档,没有执行php文件,反而提示文件下载并询问存放路径。

(2)Apache2提示无权读取cgi-bin目录的文件。

问题(1)是由于没有安装Apache2的php模块导致的,而问题(2)是由于Apache2没有足够的权限操作cgi-bin目录中的php文件。安装以下模块可以解决:

sudo apt-get install libapache2-mod-php5

sudo apt-get install libapache2-mod-suphp

在Ubuntu中搭建Apache2+Subversion环境

在Ubuntu中搭建Apache2+Subversion环境

以下各项操作基于Ubuntu10.10 desktop版本,其他版本估计也是类似,差别不大。

1、安装软件
安装apache2: sudo apt-get install apache2
(Ubuntu安装完上述软件后,会自动启动web服务,我们可以通过浏览器访问http://localhost。如果一切正常的话,应该能看到一个非常简陋的html页面)
安装subversion: sudo apt-get install subversion
安装apache的svn模块: sudo apt-get install libapache2-svn

2、创建subversion库

创建目录 sudo mkdir -p /var/local/svn/repos

创建subversion库 sudo svnadmin create /var/local/svn/repos

将所有权授予Apache(www-data) sudo chown -R www-data:www-data /var/local/svn/repos

3、配置Apache2(使用基本的用户名和密码验证方式)

修改/etc/apache2/mods-available/dav_svn.conf,完成后的文件如下:

<Location /mss_svn>

DAV svn

SVNPath /var/local/svn/repos

AuthType Basic

AuthName “Subversion Repository”

AuthUserFile /etc/subversion/passwd

Require valid-user

</Location>

创建用户及密码: sudo htpasswd -c /etc/subversion/passwd yxh

此时系统会提示输入用户yxh的密码。用户名和密码保存在上述passwd文件中。

4、启动Apache2,使上述配置生效

sudo service apache2 stop

sudo service apache2 start

5、打开浏览器访问:http://localhost/mss_svn,输入用户名和密码就可以浏览svn库了。

平时使用TortoiseSVN时,也是使用http://localhost/mss_svn就可以对库进行操作了,当然,也需要输入用户名和密码。

(上述localhost也可以换成ip地址或者其他能访问的域名)