iTimothy

君看一叶舟,出没风波里

0%

不知道拥有多个VPS的童鞋,平时是怎样来管理VPS的?在Windows下,我一般用SecureCRT来对VPS进行管理,原因是SecureCRT提供Tab标签管理的方式,多个VPS可以同时进行连接,并通过标签页进行快速切换,非常方便。至于在Linux下,我就只好老老实实的开个Console来连接VPS了。不过,今天发现一个很不错的开源软件,试用了一下,果然是Linux下管理多个VPS的利器,而且还有很多功能非常实用。

Pac Manager的官方地址,在SourceForge上:http://sourceforge.net/projects/pacmanager/ Linux下,可以直接下载发布的deb安装包进行安装。安装Pac Manager,还需要依赖另外一个安装包:libgnome2-vte-perl_0.09-1_i386.deb (64位系统,需要安装这个 libgnome2-vte-perl_0.09-1_amd64.deb),需要先安装依赖的安装包,再安装Pac Manager,否则会提示错误,找不到依赖的安装包,无法进行安装。

安装好后,就可以在主菜单的Internet子菜单中,找到Pac了。点击,即可启动。

阅读全文 »

过完了元旦节,突然想起很久没来更新下了,这里不得不提一下这个悲剧的元旦。元旦回了老家,不过这天气实在是不厚道,好不容易等到放假,却连着下了两三天的雨,冷得要命,所以大部分时间都宅在家里。不过悲剧似乎还没完结,整个元旦,是nginx的502 bad gateway陪着我渡过的。以前还觉得Nginx+php-fpm(FastCGI方式)比较稳定,不过貌似php的请求量一大起来,整个php-fpm就崩掉了。于是,整个假期,我的BlackBerry 9000一直收到监控宝发来的邮件:你的网站无法访问,出现502 bad gateway错误!

无赖之下,请教了JiuCool童鞋,得知php-fpm的确负载能力比较一般,并且JiuCool童鞋强烈推荐使用Nginx作为前端服务器,用Apache替代掉php-fpm来处理PHP的动态脚本解析,Apache的稳定性和php-fpm相比,有压倒性的优势。

于是,火速从老家赶回成都后,开始了又一轮的折腾。在网上找到一个LNAMP的一键安装包,一切都自动化安装,还挺不错,只是备份之前的VPS数据,费了很长的时间。不过昨晚的折腾,似乎并不成功,一键安装包编译PHP的源码的时候,老是报错,遇到灵异事件,遂放弃之。直到第二天,继续开始折腾这个一键安装包,终于成功了。从后来的观察来看,Nginx配合Apache确实比较给力,貌似内存占用比之前的LNMP方式还要少一些,究竟性能如何,还需进一步观察……

VPS重装系统,确实是个体力活,累……

虽然Ubuntu 11.04发布的时间还有点早,不过作为一个Ubuntu的Fans,还是怀着期待的心情。于是,我在我的Blog上放了一个Ubuntu 11.04发布的倒计时器(见右边)

如果你也有兴趣,可以参考wowubuntu放出的代码,有大图标和小图标版本,还有迷你型和文字型,可以直接嵌入到你的blog或者BBS中。 由此传送到Wow! Ubuntu

掩饰不住内心的激动,哥还是做出了一个很艰难的决定,决定把这个不错的PushMail服务端跟大家分享一下。yuchberry,是一个国人的程序员开发的用于黑莓的PushMail服务端程序。它的好处不言而喻:开源、免费、而且发送、接受的邮件不带广告。 yuchberry的官网地址:http://code.google.com/p/yuchberry/

在接触到yuchberry之前,我用过SmartMail,和ShangMail(尚邮),都是一些比较有名的第三方PushMail软件,不过用过后还是有不尽人意的地方。SmartMail的服务器端轮询时间太长,好像最短只能设为30分钟,这样实时性大打折扣。ShangMail,比较方便,可以绑定多个邮箱,不过比较讨厌的是,免费版的所有邮件,都会加上广告尾巴。而且使用免费版,我发现有时候PushMail的速度会很慢,估计是用户太多的问题。

其实上面的一些缺点,还不是关键问题,最关键最关键的是:使用第三方的PushMail服务,会需要你向第三方提供你的邮箱密码,这样,服务端程序才能够登录你的邮箱,去检索是否有新邮件。这也是我最担心的一点,毕竟密码都被第三方知道了,邮箱的安全性确实比较难保障,尤其这些第三方提供商,又是在国内……

既然把邮箱密码提供给第三方,整天惶惶不可终日,不如自己来作那个第三方。yuchberry,就是这样的一个解决方案,让你也来过足一翻自己DIY搭建PushMail服务端的瘾。yuchberry的代码是用java实现的,虽然我并不是搞java的,不过配置一下服务端还是能搞定的。并且,用java的好处,是java的程序都是以字节代码的形式,在java虚拟机中运行,这也成为跨平台的一个有利条件。yuchberry的官方提供的批处理文件,是运行在windows下的,不过这也不麻烦,有Linux服务器的同学,可以直接用shell脚本来启动服务端。前提是你的服务器必须安装JRE环境,不会的同学,可以参考我刚刚发的这篇文章:Ubuntu中安装JRE

阅读全文 »

JRE是Java的Runtime Environment,就像.NET的Framework一样,是Java程序运行的必要环境。在Ubuntu中,安装JRE的方法有很多,可以去官网下载.deb安装包,用dpkg的方式安装。这里要介绍一种比较简单的方法,就是适用apt-get来安装。貌似Ubuntu中默认的源是没有JRE的,需要我们手动改一下/etc/apt/sources.list,加入下面的一行地址: deb http://archive.canonical.com/ubuntu lucid partner 保存后,先用sudo apt-get update,更新一下源,这样,就会提示你,是否要更新JRE相关的包了。一路yes,回车后,JRE的安装就完成了。 最后,可以验证一下,在命令提示符处,输入java -version,会显示JRE的版本号等相关信息,表示安装完成。

我一直比较喜欢用Firefox,也算是Firefox的一个忠实粉丝了。不知道为啥,最近打开我的Blog,总是发觉速度很慢。开始,我一直认为是因为我在页面嵌入了百度广告,导致页面加载变慢,其实也不排除有这样的因素。后来发现每次打开我的blog的时候,都会在一个地方卡住一下,而且Firefox下面的状态栏,会显示正在等待superfish.com 。奇怪了,难道是我的页面被插入了脚本木马?也不像!后来从google搜索了一下这个怪异的superfish.com,发现有问题的并不只我一个。原来这是IE Tab插件捣的鬼,貌似这插件是superfish赞助的。IE Tab默认会把一个支持价格比较的功能打开,这个功能,就会去访问superfish.com。 了解了大概,二话不说,把这功能关掉即可。 具体的介绍,可以参考我在google上搜索出来的一同学的解决方法:由此传送过去

最近Linode的Fremont机房老是抽风,不是断电,就是VPS被强制重启。痛定思痛,哥最终做出了一个很艰难的决定:把VPS从Fremont搬到Dallas。或许是Fremont名气太大,导致国内的站长都一窝蜂的涌向此机房,不过哥最终需要的不是名气,一切都是浮云,哥需要的是稳定。所以,在周五晚上,喝过几两酒后,哥很镇定的做出了此决定,并联系了Linode的客服,将VPS从Fremont搬迁到Dallas.

整个搬迁的过程,可谓非常顺利,也非常便捷,都是自动化的。在客服操作之后,在偶的Linode面板,出现了如下的操作界面:

migration

Linode会给你缓冲的时间,让你提前对你的VPS做好备份,备份好后,手动关闭你的VPS,然后点击搬迁按钮。

migration3

搬迁过程也是非常自动化的,系统会自动把你的VPS镜像,从Fremont机房,同步到Dallas机房。当然,搬迁后,VPS的IP会产生变化,需要重新解析你的域名。整个搬迁过程,花了大概45分钟左右,就OK了。然后手动重新启动VPS即可。待域名解析生效后,blog就可以访问了。值得令人欣慰的是,数据是无缝迁移的,迁移后,并不需要充装系统,一切照旧。

希望VPS在Dallas能长久安定下去……

杯具发生在周五,公司组织出去玩,其间打了乒乓球,又打了网球,把BB9000一直放在裤兜里。估计是因为运动较为猛烈,出汗了,BB9000吸了主人的汗,受潮了。键盘上所有的按键都不灵了,要不就是按键乱窜的情况。

阅读全文 »

.NET中的Emit,其实是个很强大的东东,它允许你在你的程序运行时,动态的生成代码。看到这里,也许大家会联想到Reflection,的确,Reflection也是我们平时用得比较多的一种技术,通过Reflection,我们能通过程序集中的元数据,动态的生成目标程序集的Instance,并执行它。而Emit的功能,恰恰和Reflection遥相呼应,前者允许我们动态的生成代码,后者允许我们动态的“查看”和运行代码。Emit和Reflection合在一起,简直就是双剑合璧,简直就是幸福的一家……难怪,微软也很邪恶的把Emit放在了System.Reflection.Emit。

其实哥平时的开发中,用得比较多的,还是Reflection(反射)了,不过早已久仰Emit的大名,又没闲暇时间来窥探一把,最近总算比较闲了,决心研究研究强大的Emit。

话不多说,代码是最有力的说明,先献上一个通过Emit动态创建并生成程序集的例子:

using System;
using System.Reflection;
using System.Reflection.Emit;

namespace Emit_Learn
{
    class Program
    {
        static void Main(string[] args)
        {
            var name = new AssemblyName("HelloEmit");
            var assemblyBuilder =
            AppDomain.CurrentDomain.DefineDynamicAssembly(name,
            AssemblyBuilderAccess.RunAndSave); //创建程序集
              var modelBuilder = assemblyBuilder.DefineDynamicModule("HelloEmit",             "HelloEmit.dll"); //创建模块
              var typeBuilder = modelBuilder.DefineType("HelloEmit"); //定义类型
              var methodBuilder = typeBuilder.DefineMethod("Execute",                                 MethodAttributes.Public,                                 null,                                 null); //创建MethodBuilder
            var il = methodBuilder.GetILGenerator(); //获取ILGenerator,用于生成方法的IL
            il.Emit(OpCodes.Ldstr, "Hello, Emit");
            il.Emit(OpCodes.Call,                     typeof(Console).GetMethod("WriteLine",                     new Type[] { typeof(string) }));
            il.Emit(OpCodes.Ret);
            typeBuilder.CreateType();
            assemblyBuilder.Save("HelloEmit.dll"); //保存动态生成的程序集到磁盘文件

        }
    }
}

在IDE中输入以上代码,F5运行,你会发现,在你的程序的Debug目录,会生成一个HelloEmit.dll。没错,这就是我们的程序动态生成的程序集,并且它是可执行的。以上的代码,动态生成的程序集,包含一个叫HelloEmit的类,类中有一个public属性的Execute方法。方法中调用Console输出字符串:Hello,Emit

这个类,等价于如下的C#代码:

internal class HelloEmit
{
    // Methods
    public void Execute()
    {
        Console.WriteLine("Hello, Emit");
    }
}

我们也可以使用.NET Reflector一类的工具,打开生成的Dll查看,顺便验证一下。

Emit适用的场景:适用于对业务灵活性要求很高的系统,可以在运行时动态更改业务逻辑,并动态生成代码。

4.2.1的推出,Apple跳了票,不过终于在前两天放出了,果断刷之……

QQ截图未命名

以前都是直接从国内的站点下载更新文件,再从iTunes导入刷新,这次直接在iTunes上下载并刷新,感觉网速比以前快一些,不错不错……看来是RP爆发了~~

工作上的事总算告一段落,于是又开始折腾自己的blog。这次在评论功能中加入了表情效果,和一个动态的字数统计效果。

comment

表情以及字数统计的具体实现,参考了万戈的blog上的方法。有兴趣的同学请移步过去看看。

修改表情传送门: https://xiaozhou.net/go/wange_smile 修改字数统计传送门:https://xiaozhou.net/go/wange_comment

中午用iPhone上网的时候,发现blog不能打开,估计是VPS出了问题。最先开始怀疑的是VPS的IP被qiang,不过想想也不大可能。后来经验证,并非某墙所为。在google上搜索了一下最新的消息,原来是Fremont机房出现断电故障。登陆Linode后台,准备关闭和重启VPS,发现问题依旧,无果。后来干脆来到Linode的Support页面,一个大大的通知挂在上面:

status

原来网上的消息是真的。后来得知,这次断电的故障,不光影响到Linode一家的VPS,BuyVM的VPS也受了影响,因为他们的服务器也在Fremont机房。既然Linode出了这样的通知,看来他们也挺负责的,至少正在积极的解决问题中。除此之外,俺们只有默默的等待…… 从Linode的status页面,可以详细的查询到他们对于这次断电时间的处理情况:

status-linode

从发现问题,到问题解决,大概花了6小时左右,事后,从我的监控宝告警邮件,也证实了这一点。恢复后,VPS顺利的启动了,blog再次恢复访问…… 尽管这次掉电事件让俺有点不爽,不过就着Linode认真、负责、及时的处理,确实值得表扬一下。