升级到Ubuntu 8.10

花了一天多的时间将笔记本(IBM Thinkpad T43)升级到了Ubuntu新发布的8.10版本。

升级过程很顺利(就是时间比较长),其间遇到了Network Manager小程序不停地弹出消息对话框,说“找不到所需的资源,无法继续”,但不影响升级包的安装。

重启系统后,Network Manager小程序居然不能加载了,在launchpad里搜索到解决办法是只在/etc/network/interfaces文件里保留下面这两行。

auto lo
iface lo inet loopback

第二个问题是,升级后无线网卡不工作了,用dmesg | grep ipw2200查看,有如下类似的信息:

ipw2200-bss.fw request_firmware failed: Reason -2
ipw2200: Unable to load firmware: -2
ipw2200: failed to register network

google后知道是firmware加载的问题,检查/lib/firmware目录,没在当前使用中的内核目录(/lib/firmware/2.6.27-7-generic/)里找到这些firmware文件。从ipw2200的网站上下载后解压到这个目录后重启就解决了。(补充:使用原来的2.6.24内核启动系统无线网卡是正常的)

audacious不出声了?

audacious不能播放mp3有一段时间了,今天找到这个问题的原因。

如果用终端运行audacious,就会在console里看到下面的错误信息:

*** PULSEAUDIO: Unable to connect: Connection refused
MADPlug-Message: failed to open audio output: XMMS reverse compatibility output plugin

之前试过卸载再重装audacious,没用。

按照google到的结果提示的,发现系统里没有安装pulseaudio。而且,发现audacious里设置output plugin为alsa或oss就可以播放出来了。那pulseaudio为什么不行呢?

修改/etc/default/pulseaudio文件,PULSEAUDIO_SYSTEM_START=1 让pulseaudio服务在系统启动时启动。

最重要的,把自己的用户加到pulse, pulse-access, pulse-rt这3个group里,这个就是最根本的原因了。

解决Maven Jetty Plugin在Windows下的“文件锁定”问题

使用Maven进行Java的web开发,Jetty Plugin是必不可缺的插件,可以极大的提到开发效率。但在Windows环境下会遇到静态文件(html、css、js)被锁定、无法即时更新的问题。要想更新这些文件,只能先停掉Jetty,保存修改,再启动Jetty,非常不方便。
解决办法是这样的:
1、从jetty.jar中解出webdefault.xml(位于org.mortbay.jetty.webapp包下)这个文件,把这个useFileMappedBuffer参数设为false

useFileMappedBuffer true

2、把修改后的webdefault.xml文件跟pom.xml放在一起
3、修改pom.xml里的Jetty Plugin的配置,加入webdefault.xml

... org.mortbay.jetty
maven-jetty-plugin
6.1.7

/
webdefault.xml
...

...
...

一个Python脚本,让OpenVPN使用postfix邮箱帐号进行身份认证

这几天配置OpenVPN,使用了用户名密码的身份认证方式,借助已有的postfix邮箱帐号,省去了再为每个人设置用户名密码的麻烦。

原理很简单,OpenVPN服务器配置里有这样一句:

auth-user-pass-verify /etc/openvpn/auth-postfix-mailbox.py via-env

就是说要用/etc/openvpn/auth-postfix-mailbox.py这个脚本来验证用户名和密码。用户名和密码如何传递给它呢?via-env,环境变量。

脚本如下:

#!/usr/bin/env python

import os
import sys
from MySQLdb import *
import md5crypt

def auth(username, password):
conn = connect (host = 'localhost',
user = 'dbuser',
passwd = 'dbpasswd',
db = 'postfix')
cursor = conn.cursor()
cursor.execute("""
select password from mailbox
where username=%s
and active=1
""", (username))
row = cursor.fetchone()
if row == None:
return 1
crypt = md5crypt.md5crypt(password, row[0])
cursor.execute("""
select * from mailbox
where username=%s
and password=%s
and active=1
""", (username,crypt))
row = cursor.fetchone()
cursor.close()
conn.close()
if row == None:
return 1
return 0

def main():
status = 0
try:
username = os.environ['username']
password = os.environ['password']
status = auth(username, password)
except:
sys.exit(1)

sys.exit(status)

if __name__ == "__main__":
main()

由于postfix使用md5认证,所以需要用md5crypt这个模块,从这里可以下载到。

postfix和postgrey问题

公司的邮件服务器收不到外来邮件了,日志里有这样的错误:

554 Service unavailable; Client host [xxx.xxx.xxx.xxx] blocked using relays.ordb.org; ordb.org was shut down on December 18, 2006. Please remove from your mailserver.;

对应main.cf里的配置是这样的:

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_rbl_client sbl.spamhaus.org, warn_if_reject reject_rbl_client relays.ordb.org, warn_if_reject reject_rbl_client blackholes.easynet.nl, warn_if_reject reject_rbl_client dnsbl.njabl.org

改成只保留smtpd_client_restrictions = permit_mynetworks, 又有新信息出现:

postfix/smtpd[16212]: warning: problem talking to server 127.0.0.1:60000: Connection timed out

127.0.0.1:60000是postgrey工作的端口,用ps和netstat 发现postgrey进程还在,但top命令发现它占用了99%的CPU,而且用/etc/init.d/postgrey stop停不掉,只好kill掉,并改postfix里相应的设置,去掉postgrey检查:

smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks,permit_sasl_authenticated, reject_non_fqdn_recipient,reject_unauth_destination, check_policy_service inet:127.0.0.1:60000,permit

重启postfix,邮件可以收到了。再恢复smtpd_client_restrictions的配置,去掉relays.ordb.org检查,邮件可以收到。顺便搞清楚了warn_if_reject的含义:有它在时并不真正的拒绝邮件。

postgrey的问题还没找到解决办法,不知道为什么会hang在那里,暂时不用它了。

==== 2008-05-14 ====
补充: 将Berkeley DB由原来的4.3升级到4.4以后,postgrey正常了。
搜索到的相关信息:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441069
https://bugs.edge.launchpad.net/ubuntu/gutsy/+source/db4.4/+bug/153996