Ubuntu - Tony Bai

十一月 21, 2012

近期在做一些基础设施搭建的过程中，又遭遇到了公司http代理的问题。主要是很多主机上的工具只支持不带身份鉴权信息的http_proxy设置，如只支持诸如：export http_proxy='http://10.10.1.1:8090'，而不支持export http_proxy='http://tonybai:passwd@10.10.1.1:8090'这种形式的配置。

或是其命令行选项中只提供了proxy_host和proxy_port两个选项，但并不支持携带鉴权信息。而公司内部要访问外部信息还必须通过公司的带有身份鉴权的代理服务器，总而言之，弄得我十分不爽。于是乎产生一个想法：是否可以搭建一个内部http中间代理，部门内部主机通过不带身份鉴权信息的代理配置访问该中间代理，而该中间代理将内部的所有http request都转发到公司代理，同时携带配置好的身份验证信息。

对http代理这事，我完全是个小白啊，于是乎Google开来(恰逢最近Google还不给力，原因你懂的)。

最先试用了一下tinyproxy，这个工具挺小巧简单，在ubuntu下通过apt-get 可直接安装，/etc/tinyproxy/tinyproxy.conf的配置也很简单明了。但配置文件中涉及到转发到upstream proxy server的配置行只支持"Upstream host:port"而不支持"Upstream tonybai:passwd@host:port"形式，并且也没有其他地方支持身份鉴权信息的配置。在其官方bugzilla上有很多人反映这一情况，但其最新版本似乎也没有将这个功能加入，十分遗憾！

于是乎打算换一个重量级的代理工具-nginx。Ubuntu 9.04下默认安装的nginx是0.65版本。nginx功能虽强大，配置倒并不那么“复杂”，但问题在于nginx本身似乎更专注于负载均衡和反向代理，而满足我这个问题场景的资料甚少。nginx配置命令和变量太多，要想短时间搞清楚这些变量的含义还真是一件困难事。照猫画虎的尝试了几种配置，也均未能成功。翻阅了国内唯一一本nginx书籍 – 《实战nginx》，但无奈太厚，翻了三章，索性放下了。换工具！

最传统的开源免费http代理工具莫过于squid了。估计其市场占有率也是名列前茅的。Ubuntu 9.04下默认安装的squid是2.7版本，不算很老，squid官方站至今还提供2.7版本详细的配置文档。但squid默认的配置文件可是超级庞大，总共有近5k行，虽然绝大部分内容都是被注释掉的。于是乎先用命令过滤出未注释行，这些行是真正生效的配置。

关于squid如何将收到的http request转发到带身份鉴权的上级http proxy server，网上的信息也较少，不过还是让我发现一条。按照这条配置建议做了尝试。/etc/squid/squid.conf的配置摘要如下：

access_log /var/log/squid/access.log squid
debug_options ALL,1
hosts_file /etc/hosts
coredump_dir /var/spool/squid

acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

http_port 10.10.13.17:3128

http_access allow localnet
http_access allow localhost
http_access deny all

cache_peer proxy.yourcompany.com parent port_of_company_httpproxy 0 no-query default login=user:passwd
never_direct allow localnet

配置后，重启squid(sudo /etc/init.d/squid restart)。将Chrome浏览器的代理配置改为该代理，尝试打开"baidu.com"，陷入漫长等待。于是打开squid的访问日志/var /log/squid/access.log，看到如下失败信息：

1353476636.008      0 10.10.13.235 TCP_DENIED/400 1709 GET error:invalid-request – NONE/- text/html
1353476657.337      1 10.10.13.235 TCP_DENIED/400 1709 GET error:invalid-request – NONE/- text/html
1353476691.420      0 10.10.13.235 TCP_DENIED/400 1678 GET error:invalid-request – NONE/- text/htm

居然出错！换成IE浏览器，现象一样，都是这种错误。在/var/log/squid/cache.log中，还能发现下面错误：

2012/11/21 13:43:56| clientTryParseRequest: FD 12 (10.10.13.235:4247) Invalid Request

不断的修改squid.conf配置，不断地修改浏览器代理配置，不断的失败。总是修改浏览器的代理配置让我感觉十分费劲，于是我换用curl工具来测试该代理。curl是可以识别http_proxy环境变量的。将http_proxy环境变量改为export http_proxy=http://10.10.13.17:3128，在命令行敲入curl http://baidu.com，居然得到下面结果：

$ curl http://baidu.com
<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>

再回到access.log观察，居然看到了下面成功日志：

1353476863.916 0 10.10.13.235 TCP_HIT/200 677 GET http://baidu.com/ – NONE/- text/html

于是又尝试用wget下载外部文件、用subversion访问外部svn repository、rvm安装ruby包均告成功！这不就是我想要的结果吗！居然被我误打误撞到了！虽然到目前为止我仍然不知道为何浏览器发出的http request不能被识别^_^。

Squid这个http代理功能十分强大，本身就是被很多企业作为公司级http代理的工具的。其配置参考足足可以写成一本厚厚的书（市面上已经有这种书），还好我的场景用不到那些稀奇古怪的配置，目前这种状态足矣！

Go中的系统Signal处理

九月 21, 2012

8 条评论

我们在生产环境下运行的系统要求优雅退出，即程序接收退出通知后，会有机会先执行一段清理代码，将收尾工作做完后再真正退出。我们采用系统Signal来通知系统退出，即kill pragram-pid。我们在程序中针对一些系统信号设置了处理函数，当收到信号后，会执行相关清理程序或通知各个子进程做自清理。kill -9强制杀掉程序是不能被接受的，那样会导致某些处理过程被强制中断，留下无法恢复的现场，导致消息被破坏，影响下次系统启动运行。

最近用Golang实现的一个代理程序也需要优雅退出，因此我尝试了解了一下Golang中对系统Signal的处理方式，这里和大家分享。Golang 的系统信号处理主要涉及os包、os.signal包以及syscall包。其中最主要的函数是signal包中的Notify函数：

func Notify(c chan<- os.Signal, sig …os.Signal)

该函数会将进程收到的系统Signal转发给channel c。转发哪些信号由该函数的可变参数决定，如果你没有传入sig参数，那么Notify会将系统收到的所有信号转发给c。如果你像下面这样调用Notify：

signal.Notify(c, syscall.SIGINT, syscall.SIGUSR1, syscall.SIGUSR2)

则Go只会关注你传入的Signal类型，其他Signal将会按照默认方式处理，大多都是进程退出。因此你需要在Notify中传入你要关注和处理的Signal类型，也就是拦截它们，提供自定义处理函数来改变它们的行为。

下面是一个较为完整的例子：

//signal.go

package main

import "fmt"
import "time"
import "os"
import "os/signal"
import "syscall"

type signalHandler func(s os.Signal, arg interface{})

type signalSet struct {
m map[os.Signal]signalHandler
}

func signalSetNew()(*signalSet){
    ss := new(signalSet)
    ss.m = make(map[os.Signal]signalHandler)
    return ss
}

func (set *signalSet) register(s os.Signal, handler signalHandler) {
    if _, found := set.m[s]; !found {
        set.m[s] = handler
    }
}

func (set *signalSet) handle(sig os.Signal, arg interface{})(err error) {
    if _, found := set.m[sig]; found {
        set.m[sig](sig, arg)
        return nil
    } else {
        return fmt.Errorf("No handler available for signal %v", sig)
    }

panic("won't reach here")
}

func main() {
go sysSignalHandleDemo()
time.Sleep(time.Hour) // make the main goroutine wait!
}

func sysSignalHandleDemo() {
    ss := signalSetNew()
    handler := func(s os.Signal, arg interface{}) {
        fmt.Printf("handle signal: %v\n", s)
    }

    ss.register(syscall.SIGINT, handler)
    ss.register(syscall.SIGUSR1, handler)
    ss.register(syscall.SIGUSR2, handler)

    for {
        c := make(chan os.Signal)
        var sigs []os.Signal
        for sig := range ss.m {
            sigs = append(sigs, sig)
        }
        signal.Notify(c)
        sig := <-c

        err := ss.handle(sig, nil)
        if (err != nil) {
            fmt.Printf("unknown signal received: %v\n", sig)
            os.Exit(1)
        }
    }
}

上例中Notify函数只有一个参数，没有传入要关注的sig，因此程序会将收到的所有类型Signal都转发到channel c中。build该源文件并执行程序：

$> go build signal.go
$> signal

在另外一个窗口下执行如下命令：
$> ps -ef|grep signal
tonybai 25271 1087 0 16:27 pts/1 00:00:00 signal
$> kill -n 2 25271
$> kill -n 12 25271
$> kill 25271

我们在第一个窗口会看到如下输出：
$> signal
handle signal: interrupt
handle signal: user defined signal 2
unknown signal received: terminated

在sysSignalHandleDemo中我们也可以为Notify传入我们所关注的Signal集合：

signal.Notify(c, sigs…)

这样只有在该集合中的信号我们才能捕获，收到未在集合中的信号时，程序多直接退出。上面只是一个Demo，只是说明了我们可以捕捉到我们所关注的信号，并未体现程序如何优雅退出，不同程序的退出方式不同，这里没有通用方法，就不细说了，你的程序需要你专门的设计。

另外我们生产环境下的程序多是以Daemon守护进程的形式运行的。我们用C实现的程序多参考“Unix高级编程”中的方法将程序转为Daemon Process，但在Go中目前尚提供相关方式，网上有一些实现，但据说都不理想。更多的Go开发者建议不要在代码中实现Daemon转换，建议直接利用第三方工具。比如在Ubuntu下我们可以使用start-stop-daemon这个小程序轻松将你的程序转换为Daemon：

$> start-stop-daemon –start –pidfile ./signal.pid –startas /home/tonybai/test/go/signal –background -m
$> start-stop-daemon –stop –pidfile ./signal.pid –startas /home/tonybai/test/go/signal

这里注意：只有加上-m选项，pidfile才能成功创建。

start-stop-daemon在Debian系的Linux发行版中都是默认自带的。但在Redhat系Linux发行版中却没有该工具，我们可以自行安装：

wget -c http://developer.axis.com/download/distribution/apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
tar -xzf apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
cd apps/sys-utils/start-stop-daemon-IR1_9_18-2
gcc start-stop-daemon.c -o start-stop-daemon

切换到root下
cp start-stop-daemon /sbin/
chmod +x /sbin/start-stop-daemon

另外Go 1.0.2提供的二进制安装包直接在Redhat 5.6(Linux tonybai 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux)下面运行出错，提示无法找到GLIBC 2.7版本。目前解决这一问题的方法似乎只有从源码编译安装。进入到$GOROOT/src下，执行./all.bash即可。重现编译链接后的go可执行程序则运行一切正常。

标签 Ubuntu 下的文章

使用squid搭建http代理

Go中的系统Signal处理

文章

评论

分类

归档

链接

开源项目

翻译项目