Month: October 2014

  • Change FreePBX default MySQL connection

    我可能吹毛求疵了:我感觉如果要修改 FreePBX 里默认的 MySQL 的连接位置好麻烦。

    我修改成 MySQL socket 方式连接,而且也修改了 socket file 的位置,然后要修改 FreePBX 好多个文件才能让 FreePBX 对接 MySQL。大部分文件属于 FreePBX 配置文件,还好办,象填表格一样填就是。但 /var/www/html/admin/modules/userman/DB_Helper.class.php 根本没为 MySQL socket 连接方式考虑,DSN 只兼容 host 连接,所以要大改 262 行(以FreePBX 2.11.0.39为例)。

    要改成多行:

    
    if (preg_match('/^unix\((.+)\)$/', $amp_conf['AMPDBHOST'], $matches) === 1) {
    	$ampdbsocket = $matches[1];
    	$dsn = "mysql:unix_socket=".$ampdbsocket.";dbname=".$amp_conf['AMPDBNAME'];
    }
    else {
    	$dsn = "mysql:host=".$amp_conf['AMPDBHOST'].";dbname=".$amp_conf['AMPDBNAME'];
    }
    
    

    直接修改程序是我最不愿意的。FreePBX 似乎也没提供安全升级的办法,所以 User Management 模块一升级,上述修改就作废,FreePBX web portal 就出错。

  • Allow specific “anonymous” inbound SIP calls

    之前所有的 SIP 服务商都是提供 SIP 注册的帐号和密码。最近碰上一个新的 SIP 服务商,购买了一个电话号码,它只让我设置 Forward to SIP Server 或 Forward to SIP URI(当然也可以转发到普通电话号码,但那是要额外收费的,不在我考虑范围之内)。

    于是,碰到了新命题:我必须在 FreePBX 的 SIP Settings 里同时启用 Allow SIP Guests 和 Allow Anonymous Inbound SIP Calls 才能收到转发过来的 SIP calls。这两项都是我不愿意启用的设置,因为存在被 SIP hackers spamming 的风险。尽管单独启用 Allow SIP Guests 据说没有太大风险,但还是接不到电话,呼叫方会收到 FreePBX 给出的语音提示:The number you have dialed is not in service. Please check the number and dial again.

    怎样才能让来自 SIP 服务商的 anonymous calls 通过,而把其他的阻挡在外?我甚至想到了启用 Allow SIP Guests 和 Allow Anonymous Inbound SIP Calls ,但用防火墙规则只允许来自特定 host / IP 的流量。这个方法我自我评价是非常 dirty,我希望是 FreePBX 的问题在 FreePBX 内部解决。

    我几乎不带希望,搞了个试验,创建了一个 SIP trunk。它跟之前注册型的 SIP trunk 的区别就是省略了 PEER Details 项里的 username, password 和 Register String。然后,同时禁用 Allow SIP Guests 和 Allow Anonymous Inbound SIP Calls,这时 Forward to SIP URI 已经能工作;再添加一条 Inbound Route,Forward to SIP Server 也能工作了。

    这个事实推翻了我对 trunk 的原有理解—— trunk 只是一条进或出的通路。现在我知道 trunk 还能“命名”符合特定条件的“匿名”来电,起到过滤的作用。

    此外,我猜想,转发型的 SIP 服务比注册型的 SIP 服务更可靠,因为转发型的 SIP 只在有来电时把数据包转发到我的 FreePBX;而注册型的 SIP 则要不时地重注册保持连接,有时连接已经断开,而 FreePBX 不知道,要等到下个周期才重注册,于是会错过来电。不知我猜想对否?请教过路的 VOIP 专家。

     

  • WP Social Login back to working

    WP Social Login 这个插件在芳草苑上好长时间工作不正常了。无法通过 Google 帐号登录,显示的出错信息是:Oops! We ran into an issue. Request failed. Either you have cancelled the authentication or Google refused the connection.

    Google authentication failed
    Google authentication failed

    今天终于找到原因,其实也不是插件的错,而是在 Google 开发者项目设置里没有开启 Google+ API。默认是禁用,启用就行了。

    Enable Google+ API
    Enable Google+ API

    我隐约记得有消息说 Google+ API 发布以后,WP Social Login 从 Google API 转向了 Google+ API。但当时也没留意看,现在也搞不清楚 Google API 和 Google+ API 有什么区别。IT 技术发展太快了,很多概念只能浮于表面,能用足用好已经不错了。

  • Use long established business for your hosting

    前段时间用了一个名不见经传的公司的 VPS 产品。当时看它性能不错才切换过去,但是它操作极不规范,到期前不催续费,我想主动续费都没有链接可以让我续。突然有一天,它意识到有未收账款,也不通知我付款,就停了我的帐号。然后我付款,重新开通服务。中间中断了大约半天的服务,让我损失惨重——那天以后来自 Google 和 Facebook 的流量突然就下降了。这也让我百思不得其解:

    1. 我知道一个网站的 uptime 是很重要的指标,但是,好像影响过头了?以致我怀疑流量下降不是 uptime 的问题,但转折点就在宕机的那一天,是巧合吗?
    2. Google 和 Facebook 使用同样的算法?

    总之,不正规的公司是绝对不敢用了。离开之前,我自己清空数据,以下一行命令删除 MySQL 里所有的数据库,抄来的,很方便。

    mysql -uroot -pPASS -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| grep -v test | gawk '{print "drop database " $1 ";"}' | mysql -uroot -pPASS