Category: 小小草

IT 技术领域学海无涯。其实任何领域都学海无涯,无非 IT 发展太快了,让我有更多嘘唏。希望我掌握的技术有如小小草,虽然渺小,却有旺盛的生命力。

  • 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
  • Magento not rebuilding image cache

    I changed a server for Magento sites. When I migrated the sites, they looked fine. However after I flushed Magento image cache, all sites stopped working. Web pages were not completed. The code stopped rendering after the first product image’s “src”. But there was no error message afterwards.

    At first I thought it was file permission problem. But it was not.

    Then I thought it was some rubbish left over after flushing cache. So I took the advice by removing the folder media/catalog/product/cache and clearing everything under var. But the problem was still there.

    Then I realised it was php not generating images for Magento. Magento requires php-gd to generate images. My new server did not have php-gd installed. If I was installing a Magento instance, I would not get through. But I migrated the sites. So they “looked” fine.

    After installed php-gd, product images came back.

    By the way, Magento requires some other PHP extensions to run. I took the chance to install them all.
    pdo_mysql
    simplexml
    mcrypt
    hash
    gd
    dom
    iconv
    curl
    soap

  • Ngnix 502 bad gateway error after a recent php-fpm update

    I recently updated php-fpm from 5.4.16 to 5.5.16. After the update, Nginx comes up with 502 bad gateway error. Googling the error pointed me to look into permission of php socket file.

    In php-fpm 5.4.16, if no value is given to listen.mode, php socket file is assumed to 0666.

    But in php-fpm 5.5.16, if no value is given to listen.mode, php socket file is assumed to 0660.

    That is why Nginx no longer has permission to php socket and occurs 502 error.

  • Be reponsible for own content

    今天有朋友分享了以下两个图片,不知她是哪里看来的,总之她是晕了。

    Forged Libai Poem predicting Germany would win FIFA 2014
    Forged Libai Poem predicting Germany would win FIFA 2014
    Forged Libai Poem predicting Argentina would win FIFA 2014
    Forged Libai Poem predicting Argentina would win FIFA 2014

    本来我是准备一笑了之的,因为今年以来李白的各种预言诗已经看多了。但回想起昨天跟公司新员工交流,我讲到互联网以讹传讹的东西很多,而各种社交媒体让各种无节操的博主、群主们更容易为博取眼球(转化为IP、PV、粉丝数)无底线地骚动,直接导致很多真正有用的信息、权威的网站被湮没。这是我个人潜意识里排斥社交媒体的一个原因,但是如果我们不占领这个平台,会被更多的别有用心的人占领,是另一种层面的不进则退,非常无奈。但是我们控制不了人家的内容,我们所能做的惟有对自己的内容负责。我们的网站仿佛处于淤泥里,要让初访的用户知道我们是纯洁的、我们是权威的(其实也不要期待初访的用户会把我们定位得那么高,只要让他们知道我们是有节操的),有一点必须要做到的:不要出现错别字、注意各种细节,包括全半角的标点符号。这是以小见大,也是值得恒久关注的一件事。

    恰逢此时出现李白的诗,我觉得是很好的反面教材。但我又怕真的是我孤陋寡闻,以我的已知盖未知,不是科学的态度,最后让对方博主笑话,所以我专门花了半小时,考证了李白诗词全集,有979首诗词,里面既没有《赏雪杂感》,也没有《观山》,然后我再来写这篇文章。

    最后,我还是感谢互联网,瑕不掩瑜,没有她,我不可能在半小时内完成考证。这也说明另一个问题,权威(这里指的是李白诗词全集)不来自于社交媒体。要做权威,不要指望社交媒体。对社交媒体的使用方针是,要它为我们所用,而不要被它摆布(我指有些社交媒体的规则太复杂)。

  • No-IP becomes no IP today

    今年是 DDNS(动态域名)的多事之秋。5月初最早最出名的 DDNS 服务商 DynDNS 中止免费服务,所有服务项目开始收费。我在想,DynDNS 自信过了头,凭什么用户要交钱而不是直接离开 DynDNS?!

    总之,我是选择离开 DynDNS 改投 No-IP 的环抱。

    No-IP domains seized by microsoft
    No-IP domains seized by microsoft

    经过几个月观察,No-IP 还是很稳定的,直到今天,No-IP 塌了半边天。今天,我的IPPBX监控程序不停在提醒我,我家的 IP 地址和 No-IP DDNS 解析出来的 IP 不一致,这通常是在路由器掉线重拨,IP 地址刚发生改变才会收到的邮件,我不停收到几百封这样邮件,我还以为是宽带出问题了,直到吃晚饭时,收到 No-IP 发来的一封邮件:

    We want to update all our loyal customers about the service outages that many of you are experiencing today. This is NOT A TECHINCAL ISSUE WITH NO-IP.
    This morning, Microsoft served a federal court order and seized 22 of our most commonly used domains because they claimed that some of the subdomains have been abused by creators of malware. We were very surprised by this. We have a long history of proactively working with other companies when cases of alleged malicious activity have been reported to us. Unfortunately, Microsoft never contacted us or asked us to block any subdomains, even though we have an open line of communication with Microsoft corporate executives.

    We have been in contact with Microsoft today. They claim that their intent is to only filter out the known bad hostnames in each seized domain, while continuing to allow the good hostnames to resolve. However, this is not happening. Apparently, the Microsoft infrastructure is not able to handle the billions of queries from our customers. Millions of innocent users are experiencing outages to their services because of Microsoft’s attempt to remediate hostnames associated with a few bad actors.

    Had Microsoft contacted us, we could and would have taken immediate action. Microsoft now claims that it just wants to get us to clean up our act, but its draconian actions have affected millions of innocent Internet users.

    回家一测,果然是 noip.me 不解析任何子域名了。我在上面有三个子域名,全部中了躺枪。我赶紧按照 No-IP 的提示,将 DDNS 换用还未中枪的 onthewifi.com 子域名来解析。

    我只是没想通,No-IP 的域名怎么归着微软管?但这个事件说明:为了域名的健康,远离微软。小庆幸一下:我奉行的“尽量不用微软产品”的方针大致是正确的。

  • Display icon for a link shared on Moments in WeChat

    WeChat Moment Sharing
    WeChat Moment Sharing

    尽管操作起来稍微麻烦一些,但我坚持把有意思的原创留在自己的域名上,意思不大的文字和图片直接才“水”到社交网络上。

  • Hands on GeoIP for Nginx on Fedora and CentOS

    最近研究了一下如何根据用户的 IP 获得他的地理位置(我只关心 country 级,不关心 city 级),区别性地在 Ngnix 层面做一些限制性访问。这里用到 GeoIP 软件包和 MaxMind 的数据库。

    在 Fedora 20 下,Nginx (目前 1.4.7) 依赖于 GeoIP。等于说,装好 Nginx,ngx_http_geoip_module 自然就启用了,只要在两个配置文件略作修改。

    Fedora nginx -V output
    Fedora nginx -V output

    1. 在/etc/nginx/nginx.conf 里添加

    
    http {
    
    ...
    
    geoip_country /usr/share/GeoIP/GeoIP.dat;
    
    ...
    
    }
    
    

    2. 在 /etc/nginx/fastcgi_params 里添加

    
    fastcgi_param GEOIP_COUNTRY_CODE $geoip_country_code;
     fastcgi_param GEOIP_COUNTRY_NAME $geoip_country_name;
    
    

    还有其他参数可用,请自行查手册。重启 Nginx 就可以使用 GeoIP 的信息了。

    在 CentOS 6.5 下,事情要复杂一些。网上说 CentOS 下的 Nginx 同样依赖于 GeoIP,可在我这里事实并非如此。同样是最新的 1.4.7 版,Nginx for CentOS 是不带 ngx_http_geoip_module 编译的。即使我用 yum install GeoIP 安装了 GeoIP 软件包,但 Nginx 不从源码编译就不能启用 geoip 模块。

    CentOS nginx -V output
    CentOS nginx -V output

    着重提一下,我说的 CentOS 6.5 是 VPS 版,Nginx 和 GeoIP 无依赖是不是这个版本特有的?不得而知。我不想为之专门装一次 CentOS 来探究。我也不想从源码编译 Nginx,因为我太喜欢 yum,就为一个 ngx_http_geoip_module 搞砸了其他功能就不值得了。

    退而求其次,CentOS 下不妨用 php 调用 GeoIP,只是感觉同样功能用 php 实现会消耗更多资源。另外,Nginx 能进行全面的限制,而 php 无法利用 GeoIP 信息限制对静态文件的访问。但是,Nginx 的全面限制也只能阻止低级用户,不可能阻止稍有点 IT 知识、一心要绕开地理位置限制来访问的用户,所以 php 对动态文件的限制其实也起到了相同的效果。

    CentOS 下,安装 GeoIP for php,首先要装有 GeoIP,前面已经说了,要单独装:

    
    yum install GeoIP
    
    

    然后,安装  php-pecl-geoip:

    
    yum install php-pecl-geoip
    
    

    哈哈,都是我喜欢的yum。然后重启一下 php-fpm,即可在 php 下获得 geoip 信息。函数有很多,geoip_country_code_by_name()、geoip_country_name_by_name() 等等,请自行查手册。

    顺便提一下,CentOS 6.5 VPS 版安装 GeoIP 后,带来的 country 数据库(GeoIP.dat, 6 Sep, 2011)有 1,183,408 字节,而 Fedora 20 的 GeoIP country(GeoLiteCountry.dat, 18 Jun, 2013) 数据库只有 581,110 字节,从 MaxMind 网站上下载最新的 GeoLite Country 数据库(GeoIP.dat, 每月第一个周二更新)也只有668,134 字节。考虑到 MaxMind 的数据库是分免费和收费的,那么,CentOS GeoIP.dat 这么大,是不是更接近于收费版?我不知道收费版是啥样的,因此无从考证。

  • Newly installed BT Infinity keeps dropping continued

    BT new Home Hub 5 replacement
    BT new Home Hub 5 replacement

    前文说到新装的 BT Infinity VDSL 经常掉线,我拿着 log 向 BT 反映,他们二话不说,给我寄来了第二个路由器。这里还是数据说话,否则 BT 总怀疑用户 IT 能力,肯定要磨叽半天才肯换一个路由器。

    但是,很失望,换了个路由器,仍然掉线频繁。

    我想,该不是 FreePBX 在使用带来的一些通讯流量造成的吧?我是基于这么个假设:BT Infinity 不会如此不稳定,否则怎么推广啊?应该是我使用的某种应用造成的不稳定。大部分用户不会组建 FreePBX,这个问题不会被触发。

    于是我把 FreePBX 服务器搬回家,接在了 ADSL 上。真遗憾,我是为 FreePBX 升级到 BT Infinity,结果还得搬回家继续用 ADSL。不过,两害取其轻,FreePBX 在我家的 ADSL 上并没有造成频繁掉线。

    现在再看没有了 FreePBX 的 BT Infinity,确实稳定多了,偶有掉线(一天一次)。这初步验证了上一个假设。

    然后,我再一次假设,FreePBX 造成 BT Infinity 频繁掉线,不会是 VDSL 方面的问题,而是 BT Home Hub 5 似乎跟 FreePBX 不对口。

    看来得买一个商业级的 VDSL 路由器了。我相中 DrayTek Vigor 2860n Plus,犹豫着要不要买,而且心里有点不爽——我不喜欢基于一堆假设去采购。