【转】深入浅出REST

这是三年前的文章了,平时用rest用的多,而今需要自己设计一下REST API,来补习一下. 原文转自infoQ http://www.infoq.com/cn/articles/rest-introduction/

作者 Stefan Tilkov 译者 苑永凯 发布于 2007年12月25日, 蓝色字为笔者加的注释或加重部分

 

不知你是否意识到,围绕着什么才是实现异构的应用到应用通信的“正确”方式,一场争论正进行的如火如荼:虽然当前主流的方式明显地集中在基于SOAP、WSDL和WS-*规范的Web Services领域,但也有少数人用细小但洪亮的声音主张说更好的方式是REST,表述性状态转移(REpresentational State Transfer)的简称。在本文中,我不会涉及争论的话题,而是尝试对REST和RESTful HTTP应用集成做实用性的介绍。以我的经验,有些话题一旦触及就会引来众多的讨论,当涉及到这方面话题的时候,我会深入详细地阐述。

REST关键原则

大部分对REST的介绍是以其正式的定义和背景作为开场的。但这儿且先按下不表,我先提出一个简单扼要的定义:REST定义了应该如何正确地使用(这和大多数人的实际使用方式有很大不同)Web标准,例如HTTP和URI。如果你在设计应用程序时能坚持REST原则,那就预示着你将会得到一个使用了优质Web架构(这将让你受益)的系统。总之,五条关键原则列举如下:

  • 为所有“事物”定义ID
  • 将所有事物链接在一起
  • 使用标准方法
  • 资源多重表述
  • 无状态通信

下面让我们进一步审视这些原则。

为所有“事物”定义ID

在这里我使用了“事物”来代替更正式准确的术语“资源”,因为一条如此简单的原则,不应该被淹没在术语当中。思考一下人们构建的系统,通常会找到一系列值得被标识的关键抽象。每个事物都应该是可标识的,都应该拥有一个明显的ID——在Web中,代表ID的统一概念是:URI。URI构成了一个全局命名空间,使用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。

对事物使用一致的命名规则(naming scheme)最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义,在全球范围中几乎完美运行,并且能被绝大多数人所理解的规则。想一下你构建的上一个应用(假设它不是采用RESTful方式构建的)中的任意一个高级对象(high-level object),那就很有可能看到许多从使用唯一标识中受益的用例。比如,如果你的应用中包含一个对顾客的抽象,那么我可以相当肯定,用户会希望将一个指向某个顾客的链接,能通过电子邮件发送到同事那里,或者加入到浏览器的书签中,甚至写到纸上。更透彻地讲:如果在一个类似于Amazon.com的在线商城中,没有用唯一的ID(一个URI)标识它的每一件商品,可想而知这将是多么可怕的业务决策。

当面对这个原则时,许多人惊讶于这是否意味着需要直接向外界暴露数据库记录(或者数据库记录ID)——自从多年以来面向对象的实践告诫我们,要将持久化的信息作为实现细节隐藏起来之后,哪怕是刚有点想法都常会使人惊恐。但是这条原则与隐藏实现细节两者之间并没有任何冲突:通常,值得被URI标识的事物——资源——要比数据库记录抽象的多。例如,一个定单资源可以由定单项、地址以及许多其它方面(可能不希望作为单独标识的资源暴露出来)组成。标识所有值得标识的事物,领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源:一个流程或者流程步骤、一次销售、一次谈判、一份报价请求——这都是应该被标识的事物的示例。同样,这也会导致创建比非RESTful设计更多的持久化实体。

下面是一些你可能想到的URI的例子:

http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
http://example.com/processes/salary-increase-234 

正如我选择了创建便于阅读的URI——这是个有用的观点,尽管不是RESTful设计所必须的——应该能十分容易地推测出URI的含义:它们明显地标识着单一“数据项”。但是再往下看:

http://example.com/orders/2007/11
http://example.com/products?color=green 

首先,这两个URI看起来与之前的稍有不同——毕竟,它们不是对一件事物的标识,而是对一类事物集合的标识(假定第一个URI标识了所有在2007年11月份提交的定单,第二个则是绿颜色产品的集合)。但是这些集合自身也是事物(资源),也应该被标识。

注意,使用唯一、全局统一的命名规则的好处,既适用于浏览器中的Web应用,也适用于机对机(machine-to-machine,m2m)通信。

来对第一个原则做下总结:使用URI标识所有值得标识的事物,特别是应用中提供的所有“高级”资源,无论这些资源代表单一数据项、数据项集合、虚拟亦或实际的对象还是计算结果等。

将所有事物链接在一起

接下来要讨论的原则有一个有点令人害怕的正式描述:“超媒体被当作应用状态引擎(Hypermedia as the engine of application state)”,有时简写为HATEOAS。(严格地说,这不是我说的。)这个描述的核心是超媒体概念,换句话说:是链接的思想。链接是我们在HTML中常见的概念,但是它的用处绝不局限于此(用于人们网络浏览)。考虑一下下面这个虚构的XML片段:

<order self="http://example.com/customers/1234"> 
   <amount>23</amount> 
   <product ref="http://example.com/products/4554"> 
   <customer ref="http://example.com/customers/1234"> 
</customer> </product></order>

如果你观察文档中product和customer的链接,就可以很容易地想象到,应用程序(已经检索过文档)如何“跟随”链接检索更多的信息。当然,如果使用一个遵守专用命名规范的简单“id”属性作为链接,也是可行的——但是仅限于应用环境之内。使用URI表示链接的优雅之处在于,链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准,构成Web的所有资源都可以互联互通。

超媒体原则还有一个更重要的方面——应用“状态”。简而言之,实际上服务器端(如果你愿意,也可以叫服务提供者)为客户端(服务消费者)提供一组链接,使客户端能通过链接将应用从一个状态改变为另一个状态。稍后我们会在另一篇文章中探究这个方面的影响;目前,只需要记住:链接是构成动态应用的非常有效的方式。

对此原则总结如下:任何可能的情况下,使用链接指引可以被标识的事物(资源)。也正是超链接造就了现在的Web。

使用标准方法

在前两个原则的讨论中暗含着一个假设:接收URI的应用程序可以通过URI明确地一些有意义的事情。如果你在公共汽车上看到一个URI,你可以将它输入浏览器的地址栏中并回车——但是你的浏览器如何知道需要对这个URI做些什么呢?

它知道如何去处理URI的原因在于所有的资源都支持同样的接口,一套同样的方法(只要你乐意,也可以称为操作)集合。在HTTP中这被叫做动词(verb),除了两个大家熟知的(GET和POST)之外,标准方法集合中还包含PUT、DELETE、HEAD和OPTIONS。这些方法的含义连同行为许诺都一起定义在HTTP规范之中。如果你是一名OO开发人员,就可以想象到RESTful HTTP方案中的所有资源都继承自类似于这样的一个类(采用类Java、C#的伪语法描述,请注意关键的方法):

class Resource {
     Resource(URI u);
     Response get();
     Response post(Request r);
     Response put(Request r);
     Response delete();
} 

由于所有资源使用了同样的接口,你可以依此使用GET方法检索一个表述(representation)——也就是对资源的描述。因为规范中定义了GET的语义,所以可以肯定当你调用它的时候不需要对后果负责——这就是为什么可以“安全”地调用此方法。GET方法支持非常高效、成熟的缓存,所以在很多情况下,你甚至不需要向服务器发送请求。还可以肯定的是,GET方法具有幂等性[译注:指多个相同请求返回相同的结果]——如果你发送了一个GET请求没有得到结果,你可能不知道原因是请求未能到达目的地,还是响应在反馈的途中丢失了。幂等性保证了你可以简单地再发送一次请求解决问题。幂等性同样适用于PUT(基本的含义是“更新资源数据,如果资源不存在的话,则根据此URI创建一个新的资源”)和DELETE(你完全可以一遍又一遍地操作它,直到得出结论——删除不存在的东西没有任何问题)方法。POST方法,通常表示“创建一个新资源”,也能被用于调用任意过程,因而它既不安全也不具有幂等性。

如果你采用RESTful的方式暴露应用功能(如果你乐意,也可以称为服务功能),那这条原则和它的约束同样也适用于你。如果你已经习惯于另外的设计方式,则很难去接受这条原则——毕竟,你很可能认为你的应用包含了超出这些操作表达范围的逻辑。请允许我花费一些时间来让你相信不存在这样的情况。

来看下面这个简单的采购方案例子:

Sample Scenario

可以看到,例子中定义了两个服务程序(没有包含任何实现细节)。这些服务程序的接口都是为了完成任务(正是我们讨论的OrderManagement和CustomerManagement服务)而定制的。如果客户端程序试图使用这些服务,那它必须针对这些特定接口进行编码——不可能在这些接口定义之前,使用客户程序去有目的地和接口协作。这些接口定义了服务程序的应用协议(application protocol)。

在RESTful HTTP方式中,你将通过组成HTTP应用协议的通用接口访问服务程序。你可能会想出像这样的方式:

PS:这是个很好的例子

Sample Scenario, done RESTfully

可以看到,服务程序中的特定操作被映射成为标准的HTTP方法——为了消除歧义,我创建了一组全新的资源。“这是骗人的把戏”,我听见你叫嚷着。不,这不是欺骗。标识一个顾客的URI上的GET方法正好相当于getCustomerDetails操作。有人用三角形形象化地说明了这一点:

Knobs one can turn

把三个顶点想象为你可以调节的按钮。可以看到在第一种方法中,你拥有许多操作,许多种类的数据以及固定数量的“实例”(本质上和你拥有的服务程序数量一致)。在第二种方法中,你拥有固定数量的操作,许多种类的数据和许多调用固定方法的对象。它的意义在于,证明了通过这两种方式,你基本上可以表示任何你喜欢的事情。

为什么使用标准方法如此重要?从根本上说,它使你的应用成为Web的一部分——应用程序为Web变成Internet上最成功的应用所做的贡献,与它添加到Web中的资源数量成比例。采用RESTful方式,一个应用可能会向Web中添加数以百万计的客户URI;如果采用CORBA技术并维持应用的原有设计方式,那它的贡献大抵只是一个“端点(endpoint)”——就好比一个非常小的门,仅仅允许有钥匙的人进入其中的资源域。

统一接口也使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序(generic client)就是从中受益的组件的例子,例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。

总结如下:为使客户端程序能与你的资源相互协作,资源应该正确地实现默认的应用协议(HTTP),也就是使用标准的GET、PUT、POST和DELETE方法。

资源多重表述

到目前为止我们一直忽略了一个稍微复杂的问题:客户程序如何知道该怎样处理检索到的数据,比如作为GET或者POST请求的结果?原因是,HTTP采取的方式是允许数据处理和操作调用之间关系分离的。换句话说,如果客户程序知道如何处理一种特定的数据格式,那就可以与所有提供这种表述格式的资源交互。让我们再用一个例子来阐明这个观点。利用HTTP内容协商(content negotiation),客户程序可以请求一种特定格式的表述:

GET /customers/1234 HTTP/1.1
Host: example.com 
Accept: application/vnd.mycompany.customer+xml  

请求的结果可能是一些由公司专有的XML格式表述的客户信息。假设客户程序发送另外一个不同的请求,就如下面这样:

GET /customers/1234 HTTP/1.1
Host: example.com 
Accept: text/x-vcard 

结果则可能是VCard格式的客户地址。(在这里我没有展示响应的内容,在其HTTP Content-type头中应该包含着关于数据类型的元数据。)这说明为什么理想的情况下,资源表述应该采用标准格式——如果客户程序对HTTP应用协议和一组数据格式都有所“了解”,那么它就可以用一种有意义的方式与世界上任意一个RESTful HTTP应用交互。不幸的是,我们不可能拿到所有东西的标准格式,但是,或许我们可以想到在公司或者一些合作伙伴中使用标准格式来营造一个小环境。当然以上情况不仅适用于从服务器端到客户端的数据,反之既然——倘若从客户端传来的数据符合应用协议,那么服务器端就可以使用特定的格式处理数据,而不去关心客户端的类型。

在实践中,资源多重表述还有着其它重要的好处:如果你为你的资源提供HTML和XML两种表述方式,那这些资源不仅可以被你的应用所用,还可以被任意标准Web浏览器所用——也就是说,你的应用信息可以被所有会使用Web的人获取到。

资源多重表述还有另外一种使用方式:你可以将应用的Web UI纳入到Web API中——毕竟,API的设计通常是由UI可以提供的功能驱动的,而UI也是通过API执行动作的。将这两个任务合二为一带来了令人惊讶的好处,这使得使用者和调用程序都能得到更好的Web接口。

总结:针对不同的需求提供资源多重表述。

无状态通信

无状态通信是我要讲到的最后一个原则。首先,需要着重强调的是,虽然REST包含无状态性(statelessness)的观念,但这并不是说暴露功能的应用不能有状态——

事实上,在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中,要么保存在客户端上。或者换句话说,服务器端不能保持除了单次请求之外的,任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态,那么大量的客户端交互会严重影响服务器的内存可用空间(footprint)。(注意,要做到无状态通信往往需要需要一些重新设计——不能简单地将一些session状态绑缚在URI上,然后就宣称这个应用是RESTful。)

但除此以外,其它方面可能显得更为重要:无状态约束使服务器的变化对客户端是不可见的,因为在两次连续的请求中,客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档,当它要做一些处理时,这台服务器宕掉了,可能是硬盘坏掉而被拿去修理,可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接,它不会察觉到后台的服务器已经改变了。

理论上的REST

我承认:以上我所说的REST不是真正的REST,而且我可能有点过多地热衷于简单化。但因为我想有一个与众不同的开场,所以没有在一开始就介绍其正式的定义和背景。现在就让我们稍微简要地介绍一下这方面的内容。

首先,先前我并没有明确地区分HTTP、RESTful HTTP和REST。要理解这些不同方面之间的关系,我们要先来看看REST的历史。

Roy T. Fielding在他的博士学位论文(实际上你应该访问这个链接——至少对于一篇学术论文来说,它是相当易读的。此论文已被翻译成中文)中定义了术语REST。Roy曾是许多基本Web协议的主要设计者,其中包括HTTP和URIs,并且他在论文中对这些协议提出了很多想法。(这篇论文被誉为“REST圣经”,这是恰当的——毕竟,是作者发明了这个术语,所以在定义上,他写的任何内容都被认为是权威的。)在论文中,Roy首先定义一种方法论来谈论架构风格——高级、抽象的模式,来表达架构方法背后的核心理念。每一个架构风格由一系列的约束(constraints)定义形成。架构风格的例子包括“没有风格”(根本没有任何约束)、管道和过滤器(pipe and filter)、客户端/服务器、分布式对象以及——你猜到它了——REST。(PS:原来REST是一种风格)

如果对你来说这些听起来都太抽象了,那就对了——REST在本质上是一个可以被许多不同技术实现的高层次的风格,而且可以被实例化——通过为它的抽象特性赋上不同的值。比如,REST中包含资源和统一接口的概念——也就是说,所有资源都应该对这些相同的方法作出反应。但是REST并没有说明是哪些方法,或者有多少方法。

REST风格的一个“化身”便是HTTP(以及一套相关的一套标准,比如URI),或者稍微抽象一些:Web架构自身。接着上面的例子,HTTP使用HTTP动词作为REST统一接口的“实例”。由于Fielding是在Web已经(或者至少是大部分)“完善”了之后才定义的REST风格,有人可能会争论两者是不是100%的匹配。但是无论如何,整体上来说Web、HTTP和URI仅仅是REST风格的一个主要实现。不过,由于Roy Fielding即是REST论文的作者,又对Web架构设计有过深远的影响,两者相似也在情理之中。

最后,我在前面一次又一次地使用着术语“RESTful HTTP”,原因很简单:许多使用HTTP的应用因为一些理由并没有遵循REST原则,有人会说使用HTTP而不遵循REST原则就等同于滥用HTTP。当然这听起来有点狂热——事实上违反REST约束的原因通常是,仅仅因为每个约束带来的设计权衡可能不适合于一些特殊情况。但通常,违背REST约束的原因可归咎于对其好处认知的缺乏。来看一个明显的反面案例:使用HTTP GET调用类似于删除对象的操作,这违反了REST的安全约束和一般性常识(客户程序不应为此负责,服务器端开发人员大概不是有意而为之)。但在随后的文章中,我会提及更多这样或那样的对HTTP的滥用。

总结

本文试图对REST(Web架构)背后的概念提供快速的介绍。RESTful HTTP暴露功能的方式与RPC、分布式对象以及Web Services是不相同的;要真正理解这些不同是需要一些心态的转变。不管你构建的应用是仅仅想暴露Web UI还是想把API变成Web的一份子,了解下REST的原则还是有好处的。

Stefan Tilkov是InfoQ SOA社区的首席编辑,并且是位于德国和瑞士的innoQ公司的共同创始人、首席顾问和REST狂热分子首领。

查看英文原文A Brief Introduction to REST

Continue reading 【转】深入浅出REST

linux下独立安装 yum 笔记

安装yum是因为要安装asterisk, 我没有管理员权限,但是安装成功了才发现使用yum需要root权限。

先检查python版本:

python –V

依据python版本选择合适的yum版本。

我的例子是可选用yum-3.4.3

wget http://yum.baseurl.org/download/3.4/yum-3.4.3.tar.gz
tar -zxvf yum-3.4.3.tar.gz
cd yum-3.4.3
make install DESTDIR=/xxx/opt/lib/yum-3.4.3

这样就安装好了。

配置yum.conf,

yum启动时可以指定安装目录,yum会优先加载安装目录/etc/yum.conf这个配置。所以你可以在这个目录下自定义yum.conf. 这样yum就不会去找/etc/yum.conf了。

我这是看它源码cli.py才知道的,纠结……

运行

/home2/igtwonet/opt/lib/yum-3.4.3/usr/bin/yum --installroot='/xxx/opt/lib/yum-3.4.3'

如果没报错就说明可以运行了。

参见:

http://www.wallpaperama.com/forums/how-to-install-yum-problems-installing-on-linux-redhat-fedora-commands-t471.html

Continue reading linux下独立安装 yum 笔记

linux下mysql安装

记下自己安装mysql的过程:

wget http://cdn.mysql.com/Downloads/MySQL-5.1/mysql-5.1.63.tar.gz

tar zvxf mysql-5.1.63.tar.gz

cd mysql-5.1.63

# 新版本的mysql默认不带innodb故要加参数 -with-plugins=innobase  参见http://blog.prosight.me/index.php/2009/06/82
./configure --prefix=/xxx/mysql-5.1.63 --sysconfdir=/xxx/etc/lib --localstatedir=/xxxx/lib/mysql -with-plugins=innobase && make && make install

说明:

--prefix    指明将要安装的路径

--sysconfdir 指明mysql启动时加载的配置文件(my.cnf)路径目录

--localstatedir 指明变量存放目录

这三个参数都是为了确保后面安装成功后能访问这些目录,因为安装mysql不一定需要linux系统root权限。我这个例子的情况就是这样,我没有远程主机root权限,我只对某个目录有777权限,所以在这里指明三个个路径参数,并保证对这三个目录有足够的权限。

这一不下来后就要安装数据库了:

/xxx/mysql-5.1.63/bin/mysql_install_db

配置my.cnf:

首先选择一个模板拷贝到前面指明的--sysconfdir路径中

cp /xxx/mysql-5.1.63/share/mysql/my-medium.cnf /xxx/etc/lib/my.cnf

这里我选择了my-medium.cnf 这个配置模板,要对其进行修改:

1 修改端口,

2 修改socket 路径到具有777权限的路径下 如/tmp/sockt改为  /xxx/tmp/socket

3 将innodb的注释反注释掉。

再就可以启动了,默认的root是没有密码的:

/xxx/mysql-5.1.63/bin/mysqld_safe --user=root & 

这样可以启动mysql了,它的日志打在了=/xxxx/lib/mysql /xxxxx.err 中(启动提示写明了),可以据此日志分析问题。

上面的 命令可加参数--defaults-extra-file来指定配置文件路径,如:

/xxx/mysql-5.1.63/bin/mysqld_safe --defaults-extra-file=/xxxx/my.cnf --user=root &

这样启动后,应该初始化root密码 :

/xxx/mysql-5.1.63/bin/mysqladmin -u root password root  //此例中初始root用户密码为root

修改密码:

/xxx/mysql-5.1.63/bin/mysqladmin -u'root' -p'oldpasswor' password 'newpassword'

 

下面尝试连接mysql:

mysql client登陆

/xxx/mysql-5.1.63/bin/mysql -u'root' –p'root'

这样就登陆了mysql client,可进行sql操作了。

 

现在想使用heidisql远程登录,结果报1130错误,这是因为默认只允许127.0.0.1 和 localhost登陆的,这些信息配置在mysql.user表中记录。

use mysql;
select `host`,`user` from user where user='root';
发现有三条记录
127.0.0.1
localhost
主机域名

那么我们就添加一条权限,加入允许远程主机ip为10.199.1.18登陆的话:

INSERT INTO user SET Host='10.199.1.18',User='root',Reload_priv='Y', Process_priv='Y';
update user set Password = PASSWORD('root'),Select_priv='Y',Insert_priv = 'Y', Update_priv = 'Y', Delete_priv = 'Y', Create_priv = 'Y', Drop_priv = 'Y', Reload_priv = 'Y', Shutdown_priv = 'Y', Process_priv = 'Y', File_priv = 'Y', Grant_priv = 'Y', References_priv = 'Y', Index_priv = 'Y', Alter_priv = 'Y', Show_db_priv = 'Y', Super_priv = 'Y', Create_tmp_table_priv = 'Y', Lock_tables_priv = 'Y', Execute_priv = 'Y', Repl_slave_priv = 'Y', Repl_client_priv = 'Y', Create_view_priv = 'Y', Show_view_priv = 'Y', Create_routine_priv = 'Y', Alter_routine_priv = 'Y', Create_user_priv = 'Y', Event_priv = 'Y', Trigger_priv = 'Y' where `Host`='50.87.25.233';
FLUSH PRIVILEGES;

注意,密码一定要设置,同一用户每一登陆host的密码可以不同(其实同一用户连权限也可因登陆host 不同而设置不同),否则远程连接会报1045 错误。

 

然后是停止mysql:

/xxx/mysql-5.1.63/bin/mysqladmin shutdown -u'root' -p'root'

 

参见:

http://mysql-tips.blogspot.com/2005/04/setup-new-users-in-mysql.html

http://blog.ureshika.com/archives/815.html

Continue reading linux下mysql安装

linux下 vmware server安装

wget http://download3.vmware.com/software/vmserver/VMware-server-1.0.6-91891.tar.gz

tar zxvf VMware-server-1.0.6-91891.tar.gz
cd vmware-server-distrib
./vmware-install.pl

会提示询问,一路回车。

注册码:

99N00-YYNFF-2EJEK-4V79T
9952M-YM56C-2EL04-40Q1R
93N2M-YMMFV-2E60M-427A8
9340J-YW44A-2GJG7-4J3L9
91H24-YW1FZ-2G4GQ-4LKTM
9348J-YM4DA-27Q85-485JJ
934A4-YY5DV-2G0EP-4T7CM
91500-YW46F-25PAM-48QHX
9CM00-YPM6Z-25601-4212J
99M84-YY1FU-2GP24-4A12X
9902N-YWHDF-2GLAM-480LR
9902M-YW14A-27284-42P3N
91N01-YMMDC-275E7-4T7RH
9CH00-YMM4G-2EQ8N-48JK0
990AH-YWMDF-2EQA5-485RD
9158N-YWHFV-2EQ8H-48PU0
9C0AJ-YYH4Y-2GMG6-4LQU8
9902N-YYHDC-27LAJ-4822M
931AJ-YMHFC-2G7A4-48HCT
99004-YY14V-27K84-48H30

 

到这一步了, 怎么操作呢:

我开始半天找不到资料,后来发现需要安装vmware的mui才行:

# wget http://download3.vmware.com/software/vmserver/VMware-mui-1.0.3-44356.tar.gz

# tar -zxvf VMware-mui-1.0.3-44356.tar.gz

# cd vmware-mui-distrib
# ./vmware-install.pl

一路回车下去,好运行了,

访问https://主机地址:8333/ 就看到界面了,要使用主机的用户名密码登陆。(这里的主机是指安装vmare server的主机)。

哎呀我的个神,终于成功了。折腾啊! 结果进去一看,只能监视,还是不能建主机,看来只能用client console了。

 

vmware server console下载

http://download3.vmware.com/software/vmserver/VMware-server-win32-client-1.0.10-203137.zip

参见:

http://gaoxingf.blog.51cto.com/612518/188717

http://www.cyberciti.biz/tips/howto-control-vmware-server-using-web-port-8333.html

Continue reading linux下 vmware server安装

Asterisk安装

目前我还没安装成功,但已花了不少时间,此处记下:

网上找的都不靠谱,因为你的环境真不知道是怎么回事。

还是直接去官网看文档:

利用系统工具安装 https://wiki.asterisk.org/wiki/display/AST/Asterisk+Packages

源码编译安装 https://wiki.asterisk.org/wiki/display/AST/Installing+Asterisk+From+Source

我起先是看网上的帖子来安装,实际上是源码安装,这条路真是难走,开始是yum没有安装,只好去装rpm,但是安装rpm又找不到什么hearder,试了很多方法搞不定。

后来想找个rpm的安装包,http://www.rpmseek.com 上倒是有,但是链接有问题,只好在它的ftp上搜,好不容易搜到了,下下来安装又一堆依赖没有。这条路也走不通。

还是决定安装个ubuntu虚拟机算了。

注意安装asterisk和vmware都需要管理员权限。

vmware下载 http://www.vmsky.com/dl/VMware/Server/2009/02/17/2493.html (虽是免费,官方下载要注册还要认证)。

ubuntu可参考:http://www.dujinfang.com/past/2009/11/10/zai-ubuntu-shang-an-zhuang-asterisk/

 

其实最简单的就是直接安装AsteriskNow,它是CentOs+Asterisk+Freepbx的安装镜像,我在vmware虚拟机上安装,一会就装好了。

系统启动后会提示在哪个端口可访问freepbx。
发现连ssh和ftp都可以了(都是默认端口),所以就让vm后台运行,使用xshell登陆操作,爽。
freepbx文档 http://www.freepbx.org/support/documentation 登陆需要配置用户名密码。默认admin/admin

忍耐不住激动的心情,最想尝鲜的就是 sip电话了,配置也很简单:

官方教程 http://www.freepbx.org/support/documentation/administration-guide/adding-extensions

这篇文章图片强大,不看文字就可以看懂,还包括xlite配置:

http://www.pbxinaflash.com/community/index.php?threads/how-to-add-a-sip-softphone-freepbx-and-x-lite-as-an-example.4479/

于是我添加了两个sip分机,互相之间打电话,通了,very good.

这里面自带的mysql默认端口是3306,所以可以连接数据库看看里面有什么。(参见http://blog.ureshika.com/archives/860.html)

可见有两个表

asterisk -- 这个是主库(asterisk还是freepbx或是公用?)

asteriskcdrdb --这个大概是(Call Detail Record,CDR)数据库

Continue reading Asterisk安装

openfire整合LDAP (Active Directory)

这次成功的将openfire整合windows的Active Directory:

Active Directory服务器在windows 2000 server,windows 2003上才有,可安装虚拟机,见http://blog.ureshika.com/archives/856.html.

我在windows2000 server上 安装Active Directory服务: (http://ask.zol.com.cn/q/22451.html) 。

按照Active Directoy服务设置向导来,默认的就可以,关于DNS服务器的设置我略过了,没有管它,这样可能会有问题,但是对于openfire整合AD的测试是没有太大影响的。

安装好AD server后,在Users下建立测试用户test1,设置密码。

然后将openfire的openfire.xml中的setup设置为false,这样再启动 openfire,进入控制台会开始安装步骤。

具体怎么安装依据其文档中专门的documentation/docs/ldap-guide.html来即可。

 

比较迷惑可能会是Base DN 和 Administrator DN.

因为它的文档写错了,注意Base DN中示例 cn=Users;dc=activedirectory,dc=jivesoftware,dc=com

注意橙色的分号应该是逗号cn=Users,dc=activedirectory,dc=jivesoftware,dc=com

在配置管理员这一部中需要设置AD 中存在的账户为管理员。

这样一步步下来就配置好了,openfire会将配置记录在ofproperty表中。

注意,在安装过程中如果重启了openfire,必须要重新登陆控制台,否则会安装出错。

 

稍微看了一下源码,似乎只是用AD来进行登录验证和用户系统。

Continue reading openfire整合LDAP (Active Directory)

vmware虚拟机使用笔记

几年前用vmware玩Ubuntu,没做笔记,现在要用win2000server系统,于是想安个虚拟机,结果连怎么装系统都忘了……(话说现在都ghost,几年没装系统了)。

开始是想自己安装系统,先要用Nero刻盘,注意Nero刻盘要求选择刻录可引导光盘,否则启动时会加载不了。

然后安装,对于smartdrv这个东西我还是深有映像的,结果弄半天不耐烦了,索性决定下个win2000server的vmware的虚拟镜像:

http://www.verycd.com/topics/191003/

http://www.verycd.com/topics/191003/

vmdk格式是vmware的虚拟硬盘格式,不是可直接加载的vmk,所以先要建一个虚拟机,然后将硬盘指向下载的vmdk文件就可以,启动后一切顺利,可以登录winserver2000了。

网络连接我用的是桥接方式,不用担心ip地址每次会换,一般第一次启动虚拟机后,ip地址就不会换。

Continue reading vmware虚拟机使用笔记

Nuance Say Anything SLM

今天稍微瞄了一下slm估计以后都不会用这个摸不着头脑的东西,这里留个纪念。

voxeo是支持SLM语法的http://www.vxml.org/frame.jsp?page=grxmlbasics.htm

里面有个pdf http://community.voxeo.com/vxml/docs/nuance-8.5-grammar.pdf

pdf这里面讲了怎样编译SLM,貌似很繁琐哦,先要tranning,再要写gsl,再要编译……,至少要上千个case才能保证质量。

本来想试一下来着的,找到这个链接http://www.nuance.com/speech/training/catalogdetails.asp?CatalogcourseID=20

只看到醒目的大字1350 USD ,其他什么信息都没有,看来没法了。

貌似nuance的信息都要花钱,不花钱连个文档都没有,更不说开发测试了。

Continue reading Nuance Say Anything SLM

php mail 在windows下的配置

php 的mail函数可以发邮件,它的配置是在php.ini中设置的,一般linux上很方便,众多VPS,host一定会为你设置好。

但是在windows中开发怎么配置呢?

可使用sendmail来通过远程smtp服务器来发邮件。(我这里只讲发邮件,对于一般开发是足够了)

下载sendmail http://www.glob.com.au/sendmail/sendmail.zip

解压到目录例如c:/sendmail

编辑sendmail.ini

smtp_server=smtp服务器地址
auth_username=邮箱登录名
auth_password=邮箱密码
force_sender=发件人地址全写 这个如果不配置可能导致无法发送,但是我实际测试可以不写。

反注释debug_logfile=debug.log这一句以便调试

 

编辑php.ini

sendmail_from = you@yourdomain.com 这个我没写也可以发邮件
sendmail_path = “c:/sendmail/sendmail.exe -t –i”

 

注意force_sender和sendmail_from这两个配置都是为了自动加上From头,但是我的环境即使都设置了,还是没有在邮件头中加上From,导致550 Administrative prohibition错误。

最后只好在mail函数调用时在additional_headers这个参数中包含From,例如

 
<?php
mail('xxxx@gmail.com', "Test Email", 'good email','From: xxxx@ig2net.info' )
?>

这样就可以了。

注意From由于安全的原因,可以使其他域名的随意账户,即是此账户不存在,但是如果是配置的邮件服务器的域名,则必须存在。

例如上例中我使用本域名admin@ig2net.info 账户作为邮件服务器,那么'From: xxxx@ig2net.info' 这样发送必须有'xxxx@ig2net.info'  这个账户,否则发不出去。

然而如果使用From: abcd@somedomain.com 作为发件人,那是绝对可以发出去的。当然这可归于垃圾邮件。

 

今天碰到一个问题是,由于我的域名改了,本机测试的邮件发不出去了,打开sendmail的debug.log一看,似乎是验证成功的,但是接着一大堆乱码。我尝试将smtp_ssl设置为none则解决了此问题。

 

参见:

http://www.devcha.com/2010/04/how-to-send-emails-from-php-on-windows.html

Continue reading php mail 在windows下的配置

移动web框架比较

目前初步比较一下,我对移动开发还是羡鱼阶段。

这里初步介绍了Titanium及PhoneGap与Sencha Touch及jQuery Mobile的关系。http://mobile.51cto.com/hot-274040.htm

Sencha Touch及jQuery Mobile都支持PhoneGap包装。

从这里看主要存在性能问题, 这也是我最关心的问题。 http://iunbug.appspot.com/article.html?objNews.id=277001

这里的讨论值得看看 http://www.v2ex.com/t/30046

主要认为:

jQuery Mobile不上不下(找别的轻量级的代替,甚至可以不用它自己写),性能比Sencha Touch好不了多少,bug多,对android支持不好,更不说别的,支持没有Sencha Touch强。

Sencha Touch(iphone,android)支持较好对于正常网站式的应用又不太适合(想想extjs和jquery的区别就知道了。)

后来又出来个http://jqmobi.com/  官方介绍体积小,性能好。

http://tech.it168.com/a2012/0202/1305/000001305922.shtml

不过它太新鲜,目前还很少有人用,经验则无从说起了。

 

 

最近开始了解Android,这一路下来真是一肚子不爽,真怨恨自己怎么不是高富帅,不然早就买个mac本搞ios了,这里再补充一下:

 

这几篇文章值得看看

http://mobile.51cto.com/hot-273779.htm

http://stackoverflow.com/questions/1482586/comparison-between-corona-phonegap-titanium

http://nocreativity.com/blog/native-development-titanium-corona-unity-phonegap-and-more

上面这篇算是稍微给了个意见,相对于phonegap更愿意使用titanium,何况titanium是开源免费的

 

http://mobile.51cto.com/web-338270.htm

 

我也不确定自己想用什么,开发个小程序真不想写一堆原生代码,又是java又是objectc,但是第三方框架最担心的是闪退和性能,这要实际试试才知道,开发游戏我肯定是使用原生程序。我可能会选择titanium吧。

Continue reading 移动web框架比较

Pagination


Total views.

© 2013 - 2024. All rights reserved.

Powered by Hydejack v6.6.1