（本篇日志为How to fix your Python virtualenv after a Homebrew Python upgrade的翻译文档）

pvpanic设备是在Qemu-1.5的时候引入的一个ISA设备[1]， 旨在让hypervisor可以感知guest kernel panic，并作出相应的处理。 在目前的实现中，pvpanic使用了一个固定的I/O端口（默认为0x505）， 向这个端口的bit 0写入1的时候，即意味着guest kernel panic发生了。

首先，先来玩一玩这个设备，看看它到底会干点啥。

青蛙目前用的Ubuntu Saucy 系统上面的 Qemu 版本是1.6.0。 由于pvpanic设备在设计过程中并没有过多的考虑windows guest的情况， 并且libvirt支持这个设备也遇到了困难，所以qemu的开发者们曾经就这个设备发生了一大串的讨论[2]。 所以在现在的Qemu 1.7.*, 1.6.*, 1.5.4+中，这个功能都是默认关闭的， 要使用这个pvpanic，还需要几条额外的选项：

qemu-system-x86_64 -name test-pvpanic -nodefaults -cpu host -m …

基于某些众所周知的原因，在天朝上网非常需要勇气和技术。 今天在跟某人聊天时了解到Chrome竟然没办法使用proxy进行DNS查询<1>， 导致DNS查询结果持续被污染。 虽然用proxychains能把一切流量塞进代理里面， 不过用proxychains启动浏览器的话，各种自动代理插件就失效了，所以这是个得不偿失的方法。 青蛙晚上的时候突然想到iptables是不是可以把DNS查询流量转发进ssh tunnel呢？ 上网google一番之后，发现这是可行的，而且其实用不到iptables，只要nc就够了。

要用SSH Tunnel转发DNS流量，最大的问题是要把DNS协议使用的UDP协议转换为TCP协议，然后在proxy端还要转换回来。 所以目前青蛙想到的方案有一个很大的缺陷，就是如果ssh服务器上不提供nc命令的话，下面的操作是没法完成的。

首先，用SSH连接ssh服务器，这里青蛙打了一套组合拳，ssh -L + -D组合，分别负责DNS流量和普通数据流量：

ssh -D1080 -L5353:127.0.0.1:5353 user@ssh-server

-L 参数的目的是在本地机器上打开一个5353端口，发送到这个端口的数据都会被转发到ssh服务器上的5353端口上。

然后，在ssh服务器上执行：

server$ mkfifo /tmp/fifo
server …

CSDN的密码泄漏事件被爆出之后，在Twitter和Weibo上引起了广泛的反响，很多人质疑国内网站的安全管理工作，竟然敢直接用明文保存密码。有一点常识的Web应用开发人员都应该知道直接在数据库里明文形式的密码是相当不安全的。但是为什么还有那么多人仍然这样做呢？他们出于什么目的呢？引人深思呀。

一个网站到底应该怎么保存用户的密码才安全呢？又怎么应该设计登录流程呢？ 酷壳上有两篇文章介绍的不错：你会做Web上的用户登录功能吗？ 和 Web开发中需要了解的东西。

青蛙除了大学的时候搞的那个神马选课系统，基本就没有做过Web应用，就从一个Web用户的角度唠叨几句算了。

首先，是我们到底需要多少个密码？ 只有一个显然不行，如果使用这个密码的网站有一个不靠谱，把用户密码给泄漏了（被黑了也好，被无良网站卖了也好，当然在天朝还有另外一种可能：被政府收缴），所有的网站都必须重设密码。那每个网站都设置一个密码呢，现在是个网站都要登录，谁能记得住那么多密码呀。

为了防止密码忘掉，大体上有两种思路：

• 密码管理器 这种方法比较简单，实际就是保存一个密码。本因为浏览器就内置了记住密码的功能，把用户从繁重的记忆密码的任务中解脱出来。但是浏览器的密码记忆方式功能单一，而且跟浏览器绑定，换一个浏览器就完蛋了。还有系统自带的密码管理工具，例如KDE的KWallet之类的都会有这种问题，跟某个环境绑定，移动性不高。青蛙目前也没有好的实践经验，可以想到的方法就是加密KWallet之后放在Dropbox上，这样多台电脑之间的密码同步可以解决，但是仍然没有解决跨平台的问题。可能这个问题需要借助移动设备来完成，例如Android上的密码管理应用 …

今天的Tip是关于虚拟化的。

问题的起因是青蛙当时使用的VirtualBox的网络配置很不方便， guset系统启动之后不能改网络连接类型不说（后来的版本做了改进，但是用着还是不够舒服）， NAT模式下还不能直接跟Host系统通信。

于是青蛙痛下决心，学习了一下Linux tap和br设备的用法， 写了一个小脚本来搞定虚拟机的网络问题。

这个脚本同样也可以用于KVM的虚拟机。

这个脚本会根据配置文件建立一系列的tap设备， 然后桥街到几个br设备上去，然后在br上设置好IP， 如果需要NAT功能则配置iptables规则。

脚本文件在这里：

http://gfrog.googlecode.com/hg/script/vnet.sh

配置文件如下：

USER=gfrog           #指定建立tap设备时所用的用户名
VNET_NUM=2         #需要建立的虚拟网络数
EXITIF=eth0           #SNAT的出口接口

#以下是每个虚拟网络的配置
[vnet1]
VETH_NUM=4          #虚拟网络中包含的tap设备数
VNET_IP=11.11.1.1/24  #虚拟网络br设备上配置的ip地址
DONAT=no                  #是否需要做nat

[vnet2 …

今天继续关于ssh的话题。

青蛙本来想把今天这个主题放在昨天一起讲的，但是这两个Tip的关联不大，最后决定还是分开说。

在平时上网过程中，有可能遇到某个服务器（我们叫他S）无法访问的问题。

但是如果另外一台主机（叫做P）可以访问到S，并且我们还有P上面的ssh权限，那就可以把P当作跳板，直接访问到S。

假设要访问S上面的http（80）服务，那就执行如下命令：

ssh user@P的地址 -L 8080:S的地址:80

这个命令会在本地打开8080端口，将连接转发到S的80端口上，这样就达到了从本地直接访问S的目的。

事实上ssh的-L参数主要是用来建立一条客户端到服务器之间的安全隧道，以便安全的传输数据。

青蛙今天又开始在VMWare上继续倒腾FreeBSD。 话说上次给FreeBSD划分的虚拟硬盘太小了， csup了一下系统和ports就把分区吃光光了。 所以今天青蛙从头又装了一遍FreeBSD，在安装和升级的过程中遇到了不少问题，在这里统一做一个记录。

首先，是青蛙又把root密码搞丢了。这已经是第N次刚刚装上系统就要恢复密码了。 不过今天的原因是这样的，青蛙在安装的时候不小心修改了系统的keymap设置， 结果按照正常键盘顺序输入的字符，变成了不知道是什么符号。 当青蛙发现这个问题并改过来keymap之后，root密码就一直错误了。 没办法，上网google一下。流程如下[1]：

第一步，启动到freebsd的single user模式， 也就是出现freebsd的启动菜单的时候按4； 等着系统启动，最后会提示指定shell的位置或者按回车继续， 这里直接按回车就ok。

第二步，在shell里执行如下命令：

# fsck -p
# mount -u /
# mount -t ufs -a

第三步，用passwd修改root密码。

青蛙在这啰嗦一句：现在想想当时的错误操作就是在设置终端那步， 青蛙打开keymap的设置对话框看了一眼， 估计那个时候就直接选择了第一个键盘类型，然后就那么错了。 对比各种Linux的安装过程， keymap的设置有一个默认不做任何改变的选项， 青蛙在FreeBSD里面就没有找到， 看来FreeBSD在这种细节上还需要继续努力。

由于FreeBSD的默认shell是csh，所以青蛙用起来十分的不顺手， 上网google到几个贴心小设置 …