存档学习笔记

配置 squid_ldap_group

以前我们已经采用 LDAP 来对使用 squid 代理服务的用户进行认证,但由于 LDAP 服务器中有很多的用户,而我们只想允许一小部分人使用代理服务器,于是就需要让 squid 去验证某个用户是否属于特定的用户组。Ubuntu/Debian 的 squid 服务器软件包中已经带有相关的程序,只需要配置即可。


auth_param basic children 5
auth_param basic realm Private Proxy
auth_param basic program /usr/lib/squid/ldap_auth -h ldap.server -b "ou=People,o=bit,c=cn" -u cn -v 3
external_acl_type ldapgroup %LOGIN /usr/lib/squid/squid_ldap_group -b "o=bit,c=cn" \
-f "(&(objectclass=groupOfUniqueNames)(cn=%g)(uniqueMember=cn=%u,ou=People,o=bit,c=cn))" \
-h ldap.server
acl ldapgroup-basic external ldapgroup ccproxy
http_access deny !ldapgroup-basic
http_access allow ldap
http_access deny all

其中前 3 行让 squid 通过 LDAP 进行认证;第 4 行,让 squid 去判断用户是否在某个组中,其中 %g 表示组名,而 %u 表示用户名;第 7 行定义了一个用户组 ldapgroup-basic,它在 LDAP 服务器中的名字为 ccproxy;第 8 行禁止非 ccproxy 的用户访问,第 9 行允许 ldap 认证通过的用户访问。

以上只是配置中与 LDAP 相关的部分。

评论(1)

Jetty 的基本使用

0. 安装

直接解压即可

1. 启动

bin/jetty.sh start

2. 增加应用

在 contents 目录中创建文件 webapp.xml,至少添加如下内容:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE Configure PUBLIC “-//Mort Bay Consulting//DTD Configure//EN” “http://jetty.mortbay.org/configure.dtd”>
<Configure class=”org.mortbay.jetty.webapp.WebAppContext”>
<Set name=”contextPath”>/webapp</Set>
<Set name=”resourceBase”>/path/of/webapp</Set>
</Configure>

当 contexts 中的文件更新时,系统会自动重启相应的 Web 应用程序。

留言

PHP 编写 SOAP 客户端时日期(Date)的处理

SOAP 客户端要处理日期信息,刚开始的时候不知道怎么处理,原来只要用 strtotime() 生成参数传递过去就可以了,SOAP/Ext 会自动处理后面的情况。

评论(2)

mlterm 的配置

main:

fontsize=20
use_anti_alias = false
not_use_unicode_font=true
ENCODING=utf8

font:

ISO8859_1=-*-terminus-medium-r-normal–20-*-*-*-*-*-*-*
GB2312_80=20,-*-fangsong ti-medium-r-normal–16-*-*-*-*-*-*-*

需要安装 terminus 字体。

留言

Apache + Jetty 架设 CAS 单点登录

最近一段时间一直在断断续续地尝试 CAS 单点登录的问题,一般的文章,都是直接使用 Tomcat 或者 Jetty 等 Java 应用服务器直接配置 SSL 并安装 CAS 的,但我不太想让 Java 服务器直接 binding 到 443 端口,因此就想仍然用 Apache 处理 SSL 请求,并转发给 Jetty。在这个过程中,主要尝试了以下个问题:

  1. 如何生成自签名的证书
  2. 如何配置 Apache
  3. 如何配置 Jetty
  4. 安装、测试 CAS
  5. 把自己的 CA 证书导入到 Java 的 cacerts 文件中并测试 CAS Proxy

整个过程在 Ubuntu 7.10 上完成,现记录如下。

1. 生成自签名的证书

通常要配置 https 的服务器,都需要一个由正式的 CA 机构认证的 X509 证书。当客户端连接 https 服务器时,会通过 CA 的共钥来检查这个证书的正确性。但要获得 CA 的证书是一件很麻烦的事情,而且还要花费一定的费用。因此通常一些小的机构会是使用自签名的证书。也就是自己做 CA,给自己的服务器证书签名。

这个过程有两个主要的步骤,首先是生成自己的 CA 证书,然后再生成各个服务器的证书并为它们签名。 我是用 OpenSSL 来生成自签名证书的。

第一步是制作 CA 的证书:

openssl genrsa -des3 -out my-ca.key 2048

openssl req -new -x509 -days 3650 -key my-ca.key -out my-ca.crt

这会生成 my-ca.key 和 my-ca.crt 文件,前者存放着使用 my-ca.crt 制作签名时必须的密钥,应当妥善保管。而后者是可以公开的。上面的命令为 my-ca.key 设定的有效期为 10 年。

用命令

openssl x509 -in my-ca.crt -text -noout

可以查看 my-ca.crt 文件的内容。

有了 CA 证书之后,就可以为自己的服务器生成证书了:

openssl genrsa -des3 -out mars-server.key 1024

openssl req -new -key mars-server.key -out mars-server.csr

openssl x509 -req -in mars-server.csr -out mars-server.crt -sha1 -CA my-ca.crt -CAkey my-ca.key -CAcreateserial -days 3650

前两个命令会生成 key、csr 文件,最后一个命令则通过 my-ca.crt 为 mars-server.csr 制作了 x509 的签名证书。

需要注意的是,在执行上述第二个命令时,Common Name 选项应当输入的是服务器的域名,否则在用户通过 https 协议访问时每次都会有额外的提示信息。

用命令

openssl x509 -in mars-server.crt -text -noout

可以查看 mars-server.crt 文件的内容。

2. 配置 Apache 服务器

首先,创建 /etc/apache2/ssl 目录,将刚刚制作的 my-ca.crt、mars-server.key 和 mars-server.crt 文件拷贝到这个目录中。

接着执行命令

a2emod ssl

激活 Apache 的 SSL 模块,然后在 /etc/apache2/sites-enable/ 中添加虚拟主机,这个过程与添加普通的虚拟主机类似,不同点在于该主机的端口应为 443。配置如下:

NameVirtualHost *:443
<VirtualHost *:443>
  ServerName localhost

  DocumentRoot /var/www

SSLEngine On

  SSLCipherSuite HIGH:MEDIUM

  SSLProtocol all -SSLv2

  SSLCertificateFile /etc/apache2/ssl/mars-server.crt

  SSLCertificateKeyFile /etc/apache2/ssl/mars-server.key

  SSLCACertificateFile /etc/apache2/ssl/my-ca.crt
  <Directory /var/www>
    Order deny,allow
    Allow from localhost

</Directory>

</VirtualHost>

<VirtualHost *:80>

ServerName localhost

  DocumentRoot /var/www

<Directory /var/www>    Order deny,allow

    Allow from localhost

</Directory>

</VirtualHost>

以上配置保证了用户在访问 443 和 80 端口时可以看到相同的内容,而仅仅是使用的协议不同。修改好配置后,便可以重启 Apache 服务器,这时需要输入 mars-server.key 的密码。用浏览器访问

https://localhost/

这时应当看到一个弹出对话框,让你确认是否信任该站点的证书,选择信任后,便可以查看该站点的内容了。

由于大多数 Apache 服务器都是在服务器启动时自动启动,为了避免在启动 Apache 时输入密码,可以用以下命令生成不加密的 mars-server.key 文件:

openssl rsa -in mars-server.key -out mars-server.key.insecure

用新生成的 mars-server.key.insecure 代替原有的 key 文件即可。

3. 配置 Jetty

Jetty 是一个很容易配置的 Java Servlet/JSP 服务器,下载解压后,用命令

java -jar start.jar

即可执行。

由于我们希望通过 Apache 来访问 Jetty,就要激活 Jetty 对 AJP 的支持。可以用如下命令来启动服务器:

java -jar start.jar etc/jetty.xml etc/jetty-ajp.xml

在 Apache 这一端,首先要安装 mod-jk 模块并激活它

apt-get install libapache2-mod-jk

a2emod jk

其次要编写一个 /etc/apache2/worker.properties 文件,描述一下刚刚配置好的 jetty 服务器,文件内容如下:

worker.list=jetty

worker.jetty.port=8009

worker.jetty.host=127.0.0.1

worker.jetty.type=ajp13

worker.jetty.lbfactor=1

接着要编写一个 /etc/apache2/mods-enabled/jk.conf 文件,内容如下:

<IfModule mod_jk.c>
  JkWorkersFile "/etc/apache2/worker.properties"

  JkLogFile "/var/log/apache2/mod_jk.log"

  JkLogLevel info

  JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

  JkOptions +ForwardKeySize +ForwardURICompat
</IfModule>

最后,要修改刚刚的那个配置文件,让 mod_jk 来处理发送给 /cas/* 的请求,在虚拟主机的配置中加入如下命令:

JkMount /cas/* jetty

4. 安装、测试 CAS

下载 CAS 3.x,并将 /modules/cas-server-webapp-*.war 文件复制到 jetty 的 webapps 目录下,改名为 cas.war。

此时通过浏览器访问 https://localhost/cas/ 便可看到 CAS 的界面了。我们是使用 LDAP 服务器来存储用户信息的,关于 CAS 的定制问题,稍后在其它的文章中再阐述。

我是通过 phpCAS 来对 CAS 服务器进行测试的,首先下载 phpCAS-0.6*、解压到 /var/www/phpcas 目录中。

安装 php-curl 和 php-pear,并通过 pear 安装 PEAR::DB。

pear install DB

将 phpcas/docs/examples/ 中的文件复制到 phpcas/sources/ 目录中,修改这些文件中相关的 URL 信息,并用浏览器访问 example_simple.php,便可看到 CAS 的登录界面了。输入用户名密码后,应当可以看到登录成功的信息。

5. 将 my-ca.crt 导入到 Java 的 cacerts 文件中,并测试 CAS Proxy

CAS Proxy 的作用是让一个 CAS 的应用可以通过 CAS 来访问另一个 CAS 应用,而不需要用户多次提供密码。在这种情况下,CAS 会通过 https 访问每个 CAS 应用。由于我们的 CA 证书是自己制作的,它并不存在于 Java 的根证书列表中,这就导致 CAS 无法正常地连接我们的 https 服务器从而导致 CAS Proxy 功能不可用。要解决这个问题,必须将 my-ca.crt 文件导入到 Java 的根证书列表中。

我尝试了用 Java 提供的 keytool 来处理这个问题,但它总是要求输入 cacerts 文件的密码,而我根本没有这个密码。后来尝试用 IBM 的 keyman 解决了这个问题。keyman 是一个 GUI 程序,下载后用它来编辑 /etc/java-6-sun/security/cacerts 文件即可。注意导入密钥时,应选则 trustcacerts。

导入该密钥后,重启 Jetty 服务器,再访问 example_proxy.php 文件便可得到正确的结果了。

参考文献:

1. Van’s Apache SSL/TLS mini-HOWTO
2. Creating a self-signed SSL certificate
3. How to configure Apache SSL
4. Apache AJP13, mod_jk and mod_proxy_ajp
5. IBM KeyMan

评论(2)

永中Office在Linux环境下安装问题的总结

1. 安装

通常 Linux 都会自带 JRE,因此不一定要使用永中带的 JRE。在解压后,直接运行 java -jar dispose.jar 就可以安装了。注意要用 Java 1.5,不能用 Java 6。

2. 从桌面双击文件启动编辑

修改 /usr/share/applications/eio.desktop,将其中的 %u 替换成 %f

3. Beryl 下启动后看不到内容

此为 Java 的 Bug,在 /usr/bin/eio 中添加 export AWT_TOOLKIT=”MToolkit”,或者通过其它的方式设置这个环境变量。

以后再遇到问题慢慢补充了。

评论(1)

Mozilla XEmbed plugin 和 GTK Socket/Plug

今天抽空看了一下 Mozilla XEmbed plugins 应该如何实现,顺便给 Antler 做了个补丁。

XEmbed 的作用是把应用 A 创建的一个窗口交给应用 B 来使用,应用 A 和应用 B 可以是一个进程,也可以是不同的进程。在 GTK2 中,通过 GtkSocket 和 GtkPlug 来对这种机制进行支持。通过这个机制,可以让多个进程同时对一个窗口的显示内容进行操作。

在比较新 (1.0以后) 的 Mozilla 中,Gecko Plugin (也就是我们说的插件)就可以通过这种机制来实现。Gecko 会先通过 NPP_GetValue 来问插件是否支持 XEmbed,如果插件支持,则它会创建一个 GtkSocket,并将其 XID 通过 NPP_SetWindow 的第二个参数的 ->window 域传递过来,在插件中则可以通过这个 XID 直接创建一个 GtkPlug 并使用它了。这比使用传统的 Xt 接口要方便很多。

据说这个机制能够解决插件的一些问题,但在 Antler 中一个比较大的问题是当焦点在 scintilla 中时,它会把所有的键盘事件都吃掉,不管对它有没有用。这应当是 Netscape  Plugins API 的问题。因为在这里,来自 Macromedia 和 IBM 的开发人员指出了这个问题。

评论(1)

Async Web Server

Web 2.0 中一个很重要的技术是 AJAX,而 AJAX 对于 Web 服务器也有了不同的要求。在传统的 Web 中,优秀的 Web 服务器最重要的是其响应速度,因为处理完一个请求马上就可以去处理另外一个。然而在 Web 2.0 的一些应用中(如 Chat),发给服务器的请求要被故意延迟,从而保证用户有更好的体验。譬如:

  1. C –> S 请求
  2. S 在一段时间如10秒内不断循环,查看是否有数据可以传递给 C,若有则发送,但一定要到10秒后才关闭请求
  3. C 接到数据后立刻显示,若请求关闭,则跳转到 1。

在这种情况下,Web 服务器不仅要有良好的响应速度,还要能够在同一时刻处理更多的请求。传统的 Web 服务器如 Apache 1.x,是用进程来处理多个请求的,每个请求都在尽可能短的时间内处理完毕,即便有很多请求也能用一个进程完成处理。但如果 Web 2.0 的服务器端程序有意延迟每个请求的处理时间,则访问人数越多,需要创建的进程也越多,每个进程都要占用内存,这无疑会给 Web 服务器的性能带来巨大的影响。

在这种情况下 Web 服务器和 Web 应用程序都必须采用不同的技术来处理并发的请求,尽可能地降低处理每个请求的成本。这通常有两种方法,一个是采用线程技术,另一个是 select/poll 等系统调用来设计 Web 服务器及应用。对于 Web 服务器,目前大都已经能够很好地支持线程,但对于服务器端的编程语言如 PHP,还不能很好地支持线程,而传统 CGI 的执行方式是不能用于线程的。

当然这种需求并不是所有的 Web 应用都有,但随着 Web 2.0 的进一步普及,会有越来越多的应用有类似的需求。

留言

利用 Penrose 提供 LDAP 服务

过去,我一直以为 LDAP 服务其数据必须是放在 LDAP 数据库中的,最近又仔细研究了一下 OpenLDAP,发现它有很多的 Backend,其作用就是从不同的数据源来提取数据来提供 LDAP 服务。也就是说,我们可以把数据放在 SQL 数据库中,然后通过 LDAP 的协议来访问它。

沿着这个思路,我又发现了一个很有用的软件 Penrose,它的作用就是从不同的数据源提取数据并汇总成统一的 LDAP 服务。它是在 Apache Directory Server 的基础上编写的软件,包括服务器和 Studio 两个部分,其中 Studio 是用来编辑服务器的配置的。它嫩够支持 JDBC 和 LDAP 作为数据源,当然也可以自己编写,但对于绝大多数应用环境来说,这已经足够了。

如果使用 Penrose 来提供 LDAP 服务,那么用户管理的部分就会简单很多,而且它也可以用来弥补 OpenLDAP 没有 DIT 的问题,因为 Penrose 本身提供的就是 Virtual LDAP,因此可以按照自己的需要任意定义 LDAP 树的结构。

最后,Penrose 还支持将从各个数据库中取出的数据 cache 到一个 LDAP 服务器中,这样就可以提供高效地查询服务了。

留言

liferay 试用

最近一段时间一直在自己的机器上实验 liferay —— 一个 Portal Server,关于它的介绍,已经有很多的中文资料,这里就不说了。仅仅说说在我看来他的优势,以及目前部署时可能会有的问题。

优点:

  • 与 CAS & LDAP 集成
  • Community 的概念,可以用一个系统架多个网站
  • 页面定制很方便,所见即所得
  • 内嵌的 CMS 系统可以很方便地定制出一个网站
  • Power User 即可拥有自己的 Community,则用户可以方便地定制自己的空间。

缺点:

  • RSS Portlet 功能太弱
  • Journal Articles Portlet 功能太弱
  • Calendar 功能比较弱,没有办法与外部数据源整合
  • 整体架构太复杂(所有 Java 的东西都是如此),二次开发困难比较大

利用 liferay 可以快速部署出几个网站,但要想进一步扩充其功能是非常困难的。

评论(3)

« Previous entries