asterisk freepbx freeswitch trixbox elastix freeiris opensips fusionpbx 等等

voip这开源框架太多,都有点糊涂了,这里整理一下他们的关系:

asterisk http://www.asterisk.org/

这个不用多说

freepbx http://www.freepbx.org/

FreePBX 是一个用来控制 Asterisk 的图形化接口。

Elastix http://www.elastix.org/

系统集成了最优秀的工具,它使 Asterisk PBX 拥有一个简单易操作的界面,还增加了自己的设备,允许外界创新,使其成为开源通讯最好的软件包。Elastix 的目标就是要发展成为一个稳定、可调节和易操作的软件系统。这些特点使 Elastix 成为 Asterisk PBX 的首选。

集成SugarCRM和电话计费系统;
集成即时信息服务器 (Openfire);

trixbox http://fonality.com/trixbox/

正是为了解决 Asterisk[1] 难于配置的问题,大约在两年前,Asterisk @Home 项目悄悄地出现了。它提供了日渐完善的一体化安装方案,普通用户也可以在安装向导的指引下,完成从 Linux 系统安装到 PBX 系统配置的全部过程。2006年5月,当 AAH2.8 出现的时候,它已经整合了Asterisk[1]、FreePBX(一套基于Web的 Asterisk[1] 配置管理系统)、MySQL 和 SugarCRM[2]。在全球范围内得到了包括企业和行业用户在内的广泛用户支持。在这种形式下,社区的主要开发者开始谋求改变 AAH的本名和原定位,将 AAH 发展成一个真正的产品,于是,Trixbox1.0 产生了。2006年10月,VoIP 产品和解决方案提供商 Fonality 并购了Trixbox,使其有了进一步发展的坚实后盾。

需要指出的是,Trixbox 并不是简单地把 Asterisk 和 SugarCRM[2] 叠加在了一起,而是进行了深层次的整合,例如,在 SugarCRM [2]中,只要点击客户的电话号码,VoIP 客户端软件就能够自动进行拨号动作。

freeiris http://www.freeiris.org

Freeiris(前身为Astercon2)是一款开源的电话通信平台,含盖了计费、注册管理、PBX、数字中继、呼叫中心等业务需要。系统基于Asterisk、Perl、Linux、PHP等技术实现,在不修 改asterisk本身的情况下采用外挂形式开发。目前系统可以控制管理SIP、IAX、H323、等软协议的通信。在硬件层上,支持大量的硬件产品,包 括数字中继(ISDN PRI / ISDN BRI),模拟中继(FXO / FXS),以及各种SIP与IAX的终端设备等

似乎是国人写的

SER,OpenSER  http://www.iptel.org/ser/

这个真有点昏,SER一般指Openser,现在停止开发了,而由在其基础上又出现两个开源框架Kamailio 和 OpenSIPS 。

目前有SER+Asterisk组合,就是让SER承担SIP路由部分。

Kamailio http://www.kamailio.org/w/

参见SER

OpenSIPS http://www.opensips.org/

OpenSIPS是一个成熟的开源SIP服务器,除了提供基本的SIP代理及SIP路由功能外,还提供了一些应用级的功能。OpenSIPS的结构非常灵活,其核心路由功能完全通过脚本来实现,可灵活定制各种路由策略,可灵活应用于语音、视频通信、IM以及Presence等多种应用。同时OpenSIPS性能上是目前最快的SIP服务器之一,可用于电信级产品构建。

FreeSWITCH http://www.freeswitch.org/

FreeSWITCH 是一个开源的电话交换平台,从一个简单的软电话客户端到运营商级的软交换设备几乎无所不能。能原生地运行于Windows、Max OS X、Linux、BSD 及 solaris 等诸多32/64位平台。可以用作一个简单的交换引擎、一个PBX,一个媒体网关或媒体支持IVR的服务器等。它支持SIP、H323、Skype、Google Talk等协议,并能很容易地与各种开源的PBX系统如sipXecs、Call Weaver、Bayonne、YATE及Asterisk等通信。 FreeSWITCH 遵循RFC并支持很多高级的SIP特性,如 presence、BLF、SLA以及TCP、TLS和sRTP等。它也可以用作一个SBC进行透明的SIP代理(proxy)以支持其它媒体如T.38等。FreeSWITCH 支持宽带及窄带语音编码,电话会议桥可同时支持8、12、16、24、32及48kHZ的语音. 而在传统的电话网络中,要做到三方通话或多方通话需要通过专门的芯片来处理,其它像预付费,彩铃等业务在PSTN网络中都需要依靠智能网(IN)才能实现,而且配置起来相当不灵活

fusionpbx  http://www.fusionpbx.com/

fusionpbx是freeswitch图形WEB接口

 

搞清楚了,原来说白了就三大家族asterisk和freeswich另加SER系列的。 而且freeswitch和asterisk还是有些渊源的。 参见http://kazge.com/archives/869.html

Continue reading asterisk freepbx freeswitch trixbox elastix freeiris opensips fusionpbx 等等

【转】FreeSWITCH 与 Asterisk(译)

PS:才对asterisk感兴趣,freeswich的声音又多起来了……

转自http://www.dujinfang.com/past/2010/1/22/freeswitch-yu-asteriskyi/ 

 

Anthony Minssale/文 Seven/译

VoIP通信,与传统的电话技术相比,不仅仅在于绝对的资费优势,更重要的是很容易地通过开发相应的软件,使其与企业的业务逻辑紧密集成。Asterisk作为开源VoIP软件的代表,以其强大的功能及相对低廉的建设成本,受到了全世界开发者的青睐。而FreeSWITCH作为VoIP领域的新秀,在性能、稳定性及可伸缩性等方面则更胜一筹。本文原文在http://www.freeswitch.org/node/117, 发表于2008年4月,相对日新月异的技术来讲,似乎有点过时。但本文作为FreeSWITCH背后的故事,仍很有翻译的必要。因此,本人不揣鄙陋,希望与大家共读此文,请不吝批评指正。 --译者注

FreeSWITCH 与 Asterisk 两者有何不同?为什么又重新开发一个新的应用程序呢?最近,我听到很多这样的疑问。 为此,我想对所有在该问题上有疑问的电话专家和爱好者们解释一下。我曾有大约三年的时间用在开发 Asterisk 上,并最终成为了 FreeSWITCH 的作者。因此,我对两者都有相当丰富的经验。首先,我想先讲一点历史以及我在 Asterisk 上的经验;然后,再来解释我开发FreeSWITCH的动机以及我是如何以另一种方式实现的。

我从2003年开始接触 Asterisk,当时它还不到1.0版。那时对我来讲,VoIP还是很新的东西。我下载并安装了它,几分钟后,从插在我电脑后面的电话机里传出了电话拨号音,这令我非常兴奋。接下来,我花了几天的时间研究拨号计划,绞尽脑汁的想能否能在连接到我的Linux PC上的电话上实现一些好玩的东西。由于做过许多Web开发,因此我积累了好多新鲜的点子,比如说根据来电显示号码与客户电话号码的对应关系来猜想他们为什么事情打电话等。我也想根据模式匹配来做我的拨号计划,并着手编写我的第一个模块。最初,我做的第一个模块是app_perl,现在叫做res_perl,当时曾用它在Asterisk中嵌入了一个Perl5的解释器。现在我已经把它从我的系统中去掉了。

后来我开始开发一个Asterisk驱动的系统架构,用于管理我们的呼入电话队列。我用app_queue和现在叫做AMI(大写字母总是看起来比较酷)的管理接口开发了一个原型。它确实非常强大。你可以从一个T1线路的PSTN号码呼入,并进入一个呼叫队列,坐席代表也呼入该队列,从而可以对客户进行服务。非常酷!我一边想一边看着我的可爱的Web页显示着所有的队列以及他们的登录情况。并且它还能周期性的自动刷新。令人奇怪的是,有一次我浏览器一角上的小图标在过了好长时间后仍在旋转。那是我第一次听说一个词,一个令我永远无法忘记的词 -- 死锁。

那是第一次,但决不是最后一次。那一天,我几乎学到了所有关于GNU调试器的东西,而那只是许多问题的开始。队列程序的死锁,管理器的死锁。控制台的死锁开始还比较少,后来却成了一个永无休止的过程。现在,我非常熟悉“段错误(Segmentation Fault)”这个词,它真是一个计算机开发者的玩笑。经过一年的辛勤排错,我发现我已出乎意料的非常精通C语言并且有绝地战士般的调试技巧。我有了一个分布于七台服务器、运行于DS3 TDM信道的服务平台。与此同时,我也为这一项目贡献了大量的代码,其中有好多是我具有明确版权的完整文件(http://www.cluecon.com/anthm.html)。

到了2005年,我已经俨然成了非常有名的Asterisk开发者。他们甚至在CREDITS文件以及《Asterisk,电话未来之路》这本书中感谢我。在Asterisk代码树中我不仅有大量的程序,而且还有一些他们不需要或者不想要的代码,我把它们收集到了我的网站上。(至今仍在 http://www.freeswitch.org/node/50)

Asterisk 使用模块化的设计方式。一个中央核心调入称为模块的共享目标文件以扩展功能。模块用于实现特定的协议(如SIP)、程序(如个性化的IVR)和其它外部接口(如管理接口)等。 Asterisk的核心是多线程的,但它非常保守。仅仅用于初始化的信道以及执行一个程序的信道才有线程。任何呼叫的B端都与A端都处于同一线程。当某些事件发生时(如一次转移呼叫必须首先转移到一个称作伪信道的线程模式),该操作把一个信道所有内部数据从一个动态内存对象中分离出来,放入另一个信道中。它的实现在代码注释中被注明是“肮脏的”[1]。反向操作也是如此,当销毁一个信道时,需要先克隆一个新信道,才能挂断原信道。同时也需要修改CDR的结构以避免将它视为一个新的呼叫。因此,对于一个呼叫,在呼叫转移时经常会看到3或4个信道同时存在。

这种操作成了从另一个线程中取出一个信道事实上的方法,同时它也正是开发者许许多多头痛的源头。这种不确定的线程模式是我决定着手重写这一应用程序的原因之一。

Asterisk使用线性链表管理活动的信道。链表通过一种结构体将一系列动态内存串在一起,这种结构体本身就是链表中的一个成员,并有一个指针指向它自己,以使它能链接无限的对象并能随时访问它们。这确实是一项非常有用的编程技术,但是,在多线程应用中它非常难于管理。在线程中必须使用一个信号量(互斥体,一种类似交通灯的东西)来确保在同一时刻只有一个线程可以对链表进行写操作,否则当一个线程遍历链表时,另一个线程可能会将元素移出。甚至还有比这更严重的问题 ─ 当一个线程正在销毁或监听一个信道的同时,若有另外一个线程访问该链表时,会出现“段错误”。“段错误”在程序里是一种非常严重的错误,它会造成进程立即终止,这就意味着在绝大多数情况下会中断所有通话。我们所有人都看到过“防止初始死锁”[2]这样一个不太为人所知的信息,它试图锁定一个信道,在10次不成功之后,就会继续往下执行。

管理接口(或AMI)有一个概念,它将用于连接客户端的套接字(socket)传给程序,从而使你的模块可以直接访问它。或者说,更重要的是你可以写入任何你想写入的东西,只要你所写入的东西符合Manager Events所规定的格式(协议)。但遗憾的是,这种格式没有很好的结构,因而很难解析。

Asterisk的核心与某些模块有密切的联系。由于核心使用了一些模块中的二进制代码,当它所依赖的某个模块出现问题,Asterisk就根本无法启动。如果你想打一个电话,至少在 Asterisk 1.2中,除使用app_dial和res_features外你别无选择,这是因为建立一个呼叫的代码和逻辑实际上是在app_dial中,而不是在核心里。同时,桥接语音的顶层函数实际上包含在res_features中。

Asterisk的API没有保护,大多数的函数和数据结构都是公有的,极易导致误用或被绕过。其核心非常混乱,它假设每个信道都必须有一个文件描述符,尽管实际上某些情况下并不需要。许多看起来是一模一样的操作,却使用不同的算法和杰然不同的方式来实现,这种重复在代码中随处可见。

这仅仅是我在Asterisk中遇到的最多的问题一个简要的概括。作为一个程序员,我贡献了大量的时间,并贡献了我的服务器来作为CVS代码仓库和Bug跟踪管理服务器。我曾负责组织每周电话会议来计划下一步的发展,并试图解决我在上面提到过的问题。问题是,当你对着长长的问题列表,思考着需要花多少时间和精力来删除或重写多少代码时,解决这些问题的动力就渐渐的没有了。值得一提的是,没有几个人同意我的提议并愿意同我一道做一个2.0的分支来重写这些代码。所以在2005年夏天我决定自己来。

在开始写FreeSWITCH时,我主要专注于一个核心系统,它包含所有的通用函数,即受到保护又能提供给高层的应用。像Asterisk一样,我从Apache Web服务器上得到很多启发,并选择了一种模块化的设计。第一天,我做的最基本的工作就是让每一个信道有自己的线程,而不管它要做什么。该线程会通过一个状态机与核心交互。这种设计能保证每一个信道都有同样的、可预测的路径和状态钩子,同时可以通过覆盖向系统增加重要的功能。这一点也类似其它面向对象的语言中的类继承。

做到这点其实不容易,容我慢慢讲。在开发FreeSWITCH的过程中我也遇到了段错误和死锁(在前面遇到的多,后来就少了)。但是,我从核心开始做起,并从中走了出来。由于所有信道都有它们自己的线程,有时候你需要与它们进行交互。我通过使用一个读、写锁,使得可以从一个散列表(哈希)中查找信道而不必遍历一个线性链表,并且能绝对保证当一个外部线程引用到它时,一个信道无法被访问也不能消失。这就保证了它的稳定,也不需要像Asterisk中“Channel Masquerades”之类的东西了。

FreeSWITCH核心提供的的大多数函数和对象都是有保护的,这通过强制它们按照设计的方式运行来实现。任何可扩展的或者由一个模块来提供方法或函数都有一个特定的接口,从而避免了核心对模块的依赖性。

整个系统采用清晰分层的结构,最核心的函数在最底层,其它函数分布在各层并随着层数和功能的增加而逐渐减少。

例如,我们可以写一个大的函数,打开一个任意格式的声音文件向一个信道中播放声音。而其上层的API只需用一个简单的函数向一个信道中播放文件,这样就可以将其作为一个精减的应用接口函数扩展到拨号计划模块。因此,你可以从你的拨号计划中,也可以在你个性化的C程序中执行同样的playback函数,甚至你也可以自己写一个模块,手工打开文件,并使用模块的文件格式类服务而无需关注它的代码。

FreeSWITCH由几个模块接口组成,列表如下:

拨号计划(Dialplan): 实现呼叫状态,获取呼叫数据并进行路由。

终点(Endpoint): 为不同协议实现的接口,如SIP,TDM等。

自动语音识别/文本语音转换(ASR/TTS): 语音识别及合成。

目录服务(Directory): LDAP类型的数据库查询。

事件(Events): 模块可以触发核心事件,也可以注册自己的个性事件。这些事件可以在以后由事件消费者解析。

事件句柄(Event handlers): 远程访问事件和CDR。

格式(Formats): 文件模式如wav。

日志(Loggers): 控制台或文件日志。

语言(Languages): 嵌入式语言,如Python和JavaScript。

语音(Say): 从声音文件中组织话语的特定的语言模块。

计时器(Timers): 可靠的计时器,用于间隔计时。

应用(Applications): 可以在一次呼叫中执行的程序,如语音信箱(Voicemail)。

FSAPI(FreeSWITCH 应用程序接口) 命令行程序,XML RPC函数,CGI类型的函数,带输入输出原型的拨号计划函数变量。

XML 到核心XML的钩子可用于实时地查询和创建基于XML的CDR。

所有的FreeSWITCH模块都协同工作并仅仅通过核心API或内部事件相互通信。我们非常小心地实现它以保证它能正常工作,并避免其它外部模块引起不期望的问题。

FreeSWITCH的事件系统用于记录尽可能多的信息。在设计时,我假设大多数的用户会通过一个个性化的模块远程接入FreeSWITCH来收集数据。所以,在FreeSWITCH中发生的每一个重要事情都会触发一个事件。事件的格式非常类似于一个电子邮件,它具有一个事件头和一个事件主体。事件可被序列化为一个标准的Text格式或XML格式。任何数量的模块均可以连接到事件系统上接收在线状态,呼叫状态及失败等事件。事件树内部的mod_event_socket可提供一个TCP连接,事件可以通过它被消费或记入日志。另外,还可以通过此接口发送呼叫控制命令及双向的音频流。该套接字可以通过一个正在进行的呼叫进行向外连接(Outbound)或从一个远程机器进行向内(Inbound)连接。

FreeSWITCH中另一个重要的概念是中心化的XML注册表。当FreeSWITCH装载时,它打开一个最高层的XML文件,并将其送入一个预处理器。预处理器可以解析特殊的指令来包含其它小的XML文件以及设置全局变量等。在此处设置的全局变量可以在后续的配置文件中引用。

如,你可以这样用预处理指令设置全局变量:

<X-PRE-PROCESS cmd="set" data="moh_uri=local_stream://moh"/>

现在,在文件中的下一行开始你就可以使用 $$(moh_uri},它将在后续的输出中被替换为 local_stream://moh。处理完成后XML注册表将装入内存,以供其它模块及核心访问。它有以下几个重要部分:

配置文件: 配置数据用于控制程序的行为。

拨号计划: 一个拨号计划的XML表示可以用于 mod_dialplan_xml,用以路由呼叫和执行程序。

分词: 可标记的IVR分词是一些可以“说”多种语言的宏。

目录: 域及用户的集合,用于注册及账户管理。

通过使用XML钩子模块,你可以绑定你的模块来实时地查询XML注册表,收集必要的信息,以及返回到呼叫者的静态文件中。这样你可以像一个WEB浏览器和一个CGI程序一样,通过同一个模型来控制动态的SIP注册,动态语音邮件及动态配置集群。

通过使用嵌入式语言,如Javascript, Java, Python和Perl等,可以使用一个简单的高级接口来控制底层的应用。

FreeSWITCH工程的第一步是建立一个稳定的核心,在其上可以建立可扩展性的应用。我很高兴的告诉大家在2008年5月26日将完成FreeSWITCH 1.0 PHOENIX版。有两位敢吃螃蟹的人已经把还没到1.0版的FreeSWITCH 用于他们的生产系统。根据他们的使用情况来看,我们在同样的配置下能提供Asterisk 10倍的性能。

我希望这些解释能足够概括FreeSWICH和Asterisk的不同之处以及我为何决定开始FreeSWITCH项目。我将永远是一个Asterisk开发者,因为我已深深的投入进去。并且,我也希望他们在以后的Asterisk开发方面有新的突破。我甚至还收集了很多过去曾经以为已经丢失的代码,放到我个人的网站上供大家使用, 也算是作为我对引导我进入电话领域的这一工程的感激和美好祝愿吧。

Asterisk是一个开源的PBX,而FreeSWITCH则是一个开源的软交换机。与其它伟大的软件如 Call Weaver、Bayonne、sipX、OpenSER以及更多其它开源电话程序相比,两者还有很大发展空间。我每年都期望能参加在芝加哥召开的 ClueCon大会,并向其它开发者展示和交流这些项目(http://www.cluecon.com)。

我们所有人都可以相互激发和鼓励以推进电话系统的发展。你可以问的最重要的问题是:“它是完成该功能的最合适的工具吗?”

[1] / XXX This is a seriously wacked out operation. We're essentially putting the guts of the clone channel into the original channel. Start by killing off the original channel's backend. I'm not sure we're going to keep this function, because while the features are nice, the cost is very high in terms of pure nastiness. XXX /

[2] Avoiding initial deadlock

 

PS:摘抄网上的:

1:Asterisk是针对百人左右的小型系统,相同的硬件配置下单系统并发也就几百路(不同版本性能有一定差异,大概在 200-400之间),而根据国外爱好者测试freeswitch 可达到2000-3000路sip通道(媒体流并发),

2:Asterisk用动态链表来管理每个打开的通道,这样在多线程中非常难于管理(需要频繁的锁定和解锁)。而freeswitch每个呼叫通道都会用一个线程来管理呼叫状态,大大减少了死锁发生的几率,freeswitch核心代码高度抽象,尽量将复杂代码集中化。

3:Asterisk用DUNDi协议设计分布式系统,Fs使用外部数据库实现分布系统,做得更好,甚至可以一台服务器通过数据库注册到另一台服务器上。

4:freeswitch 支持夸平台,linux, unix, windows 等,asterisk基本只支持 linux, bsd系列。

5. freeswitch配置采用xml,asterisk采用linux下面通用配置文件格式语法,而 采用xml格式配置文件是freeswich使用者抱怨最多的部分,对于不懂xml格式的开发者在刚开始使用时是个折磨。

Continue reading 【转】FreeSWITCH 与 Asterisk(译)

Eclipse Tomcat配置Web项目

现在越来越感到jee版本要求越来越高,我最顺手的myeclipse6 渐渐会碰到越来越多的兼容问题,是时候改用高版本eclipse了。

以前用WASD6来开发,最要命的就是部署web,那个真是没有myeclipse的发布方便。

这个eclipse里的WTP似乎就是WASD里面得东西(Eclipse本身就是IBM贡献的),特不好用。

这次记一下,以免忘记了。

配置Tomcat我就不细说了,在servers中New一个,这个简单。

主要是添加web项目属性:

Snap2

注意选择版本,可看到上图中的警告,web mudule3.0需要jdk6以上。

再就是,web根目录默认是WebContent,这个似乎是和WSAD一样的。我还没试过哪里可以改这个选项。

然后就可以通过Servers里面配置的Tomcat来Publish,Start,Stop项目了。

这里Tomcat运行的目录并不是Tomcat安装目录下的webapps,而在Eclipse工作区

/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps 中

 

参见:

http://www.cnblogs.com/jspace/archive/2011/04/04/2004947.html

http://blog.csdn.net/suixingbugai/article/details/6238526

Continue reading Eclipse Tomcat配置Web项目

ATT SDK 使用笔记

这两天试用了下ATT SDK, https://devconnect-api.att.com/用武汉话总结—稀烂.

1 每个开发组织(每个组织下可有多个开发者)每年要99美刀,这个倒是和苹果看齐了,还没开始先宰你一刀。

2 我尝试SMS 和 MMS,结果发现只支持ATT 用户,这是文档上写明了的。

3 还没发现call 的api。

4 奇怪的oath。步骤比较复杂。它的示例代码getToken.jsp还有bug。

SpeechToText Api结果加入了语义分析结果,例如_PHONE (123)256-7890. _END_PHONE,这简直被驴踢了。如果想要原始结果还要自己写代码去掉。 其结果比Nuance Dragon差:

1 花费时间要长, 估计是花在web seartch上了

2 翻译结果没有Nuance精确。我怀疑它这就是用的Nuance。

3 一般只返回一个结果。

Continue reading ATT SDK 使用笔记

Worspress SyntaxHighlighter代码着色

wordpress有插件,但是我们一般都是用wlw来写文章,所以还得用wlw的插件:

wlw插件下载地址即配置说明:http://wlwsyntaxhighlighter.codeplex.com/

测试一下:

<?php
echo "hello world";	
?>

步骤是安装wlw插件,

wlw同步主题:日志/编辑日志设置/编辑/刷新主题

然后将https://code.google.com/p/syntaxhighlighter中的资源上传到你的wp中,还要在你的主题中添加代码:

<link type="text/css" rel="stylesheet" href="Styles/SyntaxHighlighter.css"></link>
<script language="javascript" src="Scripts/shCore.js"></script>
<script language="javascript" src="Scripts/shBrushCSharp.js"></script>
<script language="javascript">
window.onload = function() {
    dp.SyntaxHighlighter.ClipboardSwf = 'Scripts/clipboard.swf';
    dp.SyntaxHighlighter.HighlightAll('code');
};
 </script>

稍微有点麻烦。

 

Continue reading Worspress SyntaxHighlighter代码着色

使用Spring开发RESTful API

使用spring mvc可以实现RESTful API。这次不得不用spring,我发现我的博客里一篇spring的笔记都没有!

现在还是从头来吧。

官方文档:

http://static.springsource.org/spring/docs/

http://static.springsource.org/spring/docs/3.0.x/reference/mvc.html

官方pdf下载地址: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/pdf/spring-framework-reference.pdf

 

/ 和/*的区别:

/是默认的servlet配置(就是没有被其映射截获的都会被这个处理,包含静态资源),而/*则完全包括了所有的路劲。

http://tomcat.apache.org/tomcat-7.0-doc/default-servlet.html

 

开始就犯个错:

copy网上的

<context:component-scan base-package="xxx.*>  </context:component-scan>

结果一直无法映射,xxx包里的类根本没加载,再看文档,没那里说支持*,(有的blog里面甚至还有***).改为

<context:component-scan base-package="xxx”>  </context:component-scan>就可以了。我看还是直接看文档最靠谱.

 

关于mapping的问题

A类配置了根/abc/

B类则不能配置根为/abc/efg,配置了虽不报错也无效

那么只好在A类里配置/efg到方法中

 

关于springmvc配置和spring配置

注意springmvc的配置应该和spring的配置分开,spring的配置是指关于spring 核心功能的配置,springmvc则应该视为web mvc架构的spring实现,例如springmvc中的注解只会应用mvc相关的功能例如controller,会忽略你在其配置中配置的其他像transaction注解,甚至覆盖service注解等

所以应该在web.xml的listener中加载spring配置,而在web.xml中servlet中配置springmvc配置。而且springmvc控制器类应该和业务功能严格分离,这就要求你的springmvc控制器不能有transaction,service等注解,你必须将业务逻辑分离出来由控制器调用。

 

这个问题坑了我一把,我在springmvc中配置tranaction事务注解,结果事务注解总是没起作用,而spring却什么错误提示也没有,着实挖了个大坑。

参见:

http://stackoverflow.com/questions/10019426/spring-transactional-not-working

 

关于ServletContext

3.0之前可以使用ApplicationContextAware接口来获得WebApplicationContext,通过它来获得Servletcontext。

也可以这样:

<bean id="servletContext" class="org.springframework.web.context.support.ServletContextFactoryBean"/>

 

那么这个ServletContextFactoryBean就可以获得Servletcontext。

 

3.0之后servletContext默认就是存在Spring中的Bean,直接引用即可。

 

 

配置示例:

class="c#" name="code"><listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/spring-application.xml</param-value> </context-param>

Continue reading 使用Spring开发RESTful API

【转】深入浅出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://kazge.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安装

Pagination


Total views.

© 2013 - 2019. All rights reserved.

Powered by Hydejack v6.6.1