heidisql使用ssh远程连接mysql

一般都是使用phpmyadmin来管理远程数据库,但是也可以使用自己喜爱的mysql客户端工具配合ssh通道来连接远程数据库,其道理就似乎是个代理,用ssh工具登陆上mysql所在主机的某个端口,在本地开个端口,那么本机对此端口的请求就会连接到主机上的配置的端口上。

下面以heidisql为例。

最主要的是ssh的配置,putty大家都知道吧,用它来建立隧道。

首先你的远程服务器需要开通ssh连接,此文就不涉及内容,假定已可以通过ssh远程连接,并且检查msql是否允许此主机连接,可以通过cpanel的RemoteMysql来配置。

在putty中需要配置:

打开putty,在session中配置主机ip地址或域名以及端口。

mysqlgui2

然后配置本机到主机的映射隧道:

在tunnels中source port是你打算在本机映射的端口此例中是3307,注意不要使用已被占用的端口。

Destination中添目标mysql主机ip以及mysql端口,此例中是codex345.extremehost,端口是3306

选中local和auto点击Add,那么隧道就配置成功了。

mysqlgui3

在session中保存你的配置,点击open,此时会出现putty控制台登陆远程主机,需要你填入用户名和密码。登陆成功后,就可以在heidisql中项配置本地数据库一样配置到远程数据库的连接了。此例中练的是本地,端口是上面配置的3307,其实就是通过隧道连接到远程主机的3306端口了,是不是很方便呢。

mysqlgui4

实际开发中不喜欢每次都要在putty中输入用户名密码,而putty处于安全的考虑又不提供保存密码的功能,那么你可以使用xshell,它是一款功能更强大的商业软件,而且对个人用户免费哈哈。见http://www.netsarang.com/products/xsh_overview.html

它的配置和putty很类似,对于隧道配置如下图,其实也是一样,只不过界面改了,我在这里烂一下笔头,方便大家区分:

Snap1

 

有时连接出现SQL Error (2013): Lost connection to MySQL server at 'reading initial communication packet',错误,经测试改用ip而不是域名连接远程主机就可以解决这个问题。

Continue reading heidisql使用ssh远程连接mysql

php版本升级问题

升级到5.3注意的问题:

增加了Deprecated 错误级别 http://php.net/manual/en/migration53.deprecated.php

Deprecated features in PHP 5.3.x

PHP 5.3.0 introduces two new error levels: E_DEPRECATED and E_USER_DEPRECATED. The E_DEPRECATED error level is used to indicate that a function or feature has been deprecated. The E_USER_DEPRECATED level is intended for indicating deprecated features in user code, similarly to the E_USER_ERROR and E_USER_WARNING levels.

The following is a list of deprecated INI directives. Use of any of these INI directives will cause an E_DEPRECATED error to be thrown at startup.

Deprecated functions:

Deprecated features:

  • Assigning the return value of new by reference is now deprecated.
  • Call-time pass-by-reference is now deprecated.

Continue reading php版本升级问题

linux cron任务执行php

一般可使用cpanel 中的cron job界面来添加任务,对于执行php来说,可现在本机上执行命令测试了再加上去。

也可使用

crontab -e

来直接编辑,注意cpanel的cron脚本是没有放在这里面的。

还可以使用浏览器来执行呢:

http://www.htmlcenter.com/blog/running-php-scripts-with-cron/

 

默认情况下,crontab中执行的日志写在/var/log下,如:

#ls /var/log/cron*

/var/log/cron /var/log/cron.1 /var/log/cron.2 /var/log/cron.3 /var/log/cron.4

crontab的日志,当crond执行任务失败时会给用户发一封邮件。如果在服务器上发现一个任务没有正常执行,而crond发邮件也失败。通过看mail的日志,看是否是磁盘空间不够造成的

将cornd错误输出和标准输出日志都指向自定义的日志文件:

0 6 * * * $HOME/fro_crontab/createTomorrowTables>>$HOME/for_crontab/mylog.log 2 >&1

 

对于codeigniter来说,可参见他的源码cron.php,它是模仿http请求来做的。

参见:

http://tech.ddvip.com/2008-06/121324087945638.html

Continue reading linux cron任务执行php

openfire配置杂记

openfire最好依据目标操作系统选择版本,linux上就应该选择RPM版,这样就省却很多麻烦。比如与其他xmpp服务商的通信。openfire server上有个server to server配置,据我的经验,选择好了版本,安装好了,根本就不需要配置这个就可以和gtalk,jabber等通信,即本服务器上的用户[email protected]发送给[email protected]的消息会发送给[email protected][email protected]的发送给[email protected]消息[email protected]也收的到。

另外http://sourceforge.net/projects/kraken-gateway这个插件是提供其他流行的xmpp server的登陆的,比如gtalk,yahoo,甚至QQ。

openfire是提供离线消息的,默认这个配置也是开启的,在Server/Server Settings/Offline Message 中配置

Continue reading openfire配置杂记

http抓包分析工具

web开发有时需要用到抓包工具分析请求与返回,通常,firefox的firebug已经够用。但是对于跨页面的请求则不行,如unload事件中的请求。这时可使用httpfox这个插件来监视,它的菜单在tools/web developer中,我开始还找半天。

其余的如果不是监视到本机服务器的请求,可以使用wireshark,但是我发现有时貌似不准,Fiddler更不行了。

它们两个都不好监视对本机服务器的http请求,像rawcap这样的更是不靠谱,输入到文件,用notepad++打开全是乱码。

Continue reading http抓包分析工具

unload事件,刷新,顺序,不靠谱

window的unload事件,用起来不靠谱,为什么呢?

我做个测试来说明,在页面unload事件中做一个同步ajax请求,然后刷新页面,我来比较刷新时unload事件和get新页面请求发生的时间顺序,结果如下:

FF:
16:13:48 445766772 get
16:13:48 445766787 unload

unload在get之后

 

Chrome:
16:36:13 447111240 get
16:36:13 447111274 unload

unload在get之后

 

IE:
16:33:08 446926865 get
16:33:08 446926842 unload

unload在get之前

 

Safari:
16:38:08 447226350 get
16:38:08 447226386 unload

unload在get之后

 

Opera:
16:39:39 447317584 get

没有unload事件

 

结果是FF,Safari,Chrome竟然unload请求在get请求之后。就只IE符合正常逻辑unload完了再get。Opera索性不支持unload事件。

通过HTTP抓包分析FF是先获得新页面的html然后执行上页面的unload事件,然后开始请求新页面的资源。

如果某些处理依赖unload事件而又讲究顺序的话,那就可能对我们的程序造成问题,所以,unload事件还是尽量不用为好,不靠谱啊!

 

beforeubload也存在这个情况。

Continue reading unload事件,刷新,顺序,不靠谱

【转】Google OAUTH + OpenID解决方案

同系列文章,转载自 Google OAUTH + OpenID解决方案, 蓝色字是我加的注解或是着重提示。

 

       在前面已经介绍过OAuth与OpenID,这两种服务,Google都实现了。我们可以通过Google OAuth服务为Google 用户的资源进行授权,如用户通过第三方软件调用Google Open API操作用户的资源时,就需要用户对第三方软件授权;通过Google OpenID服务可以打通Google与其他支持OpenID服务网站之间的用户体系。现在假如有另外一个网站,也想开放自己的Open API服务,但是又不想实现OAuth服务(毕竟实现OAUTH服务还是需要一些成本的),那该怎么办?它可不可以使用Google提供的OAuth服务,授权认证交给Google来处理?可以!但是OAuth授权也是基于用户登录来实现的,Google OAuth用户体系只是Google的用户体系,那又怎么办了?OpenID!对,将网站的用户体系与Google用户体系打通,并且使用Google OAuth服务来实现授权,即Google提出的OpenID + OAUTH的解决方案。

一、 OAUTH与OpenID

前面两篇文章对OAUTH与OpenID均做过介绍,且Google均提供了这两种服务,在此我们先简要的回顾这两种服务,具体介绍请参见相关文章。

OAUTH是一种开放的,基于用户登录的授权认证方式。如当用户使用第三方软件调用Google Open API去操作自己的Google服务资源时,用户就要先对该软件授权。授权过程中,第三方软件会引导用户登录Google,进行用户鉴权,用户通过Google身份鉴权后才能对第三方软件授权。显然,Google OAUTH只能对Google用户进行鉴权,其他用户体系的用户不能直接鉴权。

OpenID是一种开放的,去用户中心的,用于打通各网站之间的用户体系的服务。在支持OpenID的网站间,你可以使用任何一个网站的帐号或者Open ID去登录任何一个网站。OpenID提供了类似单点登录的用户体验,并且用户无需在各个网站上注册就可以使用该网站的资源,将用户从繁重的帐号注册与管理工作中解脱出来。当用户使用OpenID登录没注册的网站过程中,网站会引导用户登录OP(用户OpenID注册的网站),请求OP对用户身份鉴权,用户通过OP鉴权,网站才会容许用户登录。

若将OpenID与Google OAUTH结合,OpenID将第三方网站的用户体系与Google用户体系打通后,第三方网站便可使用Google OAUTH服务,对自己的用户进行授权!交互示意图如下图所示:

二、 Google OAUTH + OpenID解决方案

Google提出了OpenID + OAUTH的解决方案,将两者揉合在一起,具体流程如下图所示:

1. Web应用请求用户登录;

2. 用户选择使用Google OpenID进行登录;

3. Web应用请求发现Google认证服务URL;

4. Google向Web应用返回XRDS信息,其中包含Google认证服务URL;

5. Web应用请求用户登录Google服务,通过请求用户授权;

6. Google引导用户登录;

7. 用户输入用户名密码进行登录,同时确认是否对第三方软件授权;

8. Google认证中心返回用户ID与授权的Request Token给Web应用;

9. 用户可以访问受保护的资源,同时可以继续第七部中Oauth认证余下的环节;

从上面的流程第五步可以看出,Google解决方案中,将OAUTH与OpenID的登录操作合并在一起、并且在登录的同时向Google发送Oauth请求,请求用户授权。这样一来,在第五步中,用户登录Google(OpenID中Google对用户鉴权),同时请求对用户授权(OAUTH中对用户授权,同时无需再次登陆,因为前面OpenID已经登录过了)。

三、Google OAUTH+OpenID Demo

Google提供了OAUTH + OpenID的DEMO,Demo演示地址如下:http://googlecodesamples.com/hybrid/

刚开始,用户既没OpenID登录也没OAUTH授权,如下图所示:

接着,点击上图中login按钮请求以Google提供的OpenID登录,如下图所示:

输入用户名与密码登录后,Google提醒您即将登陆到外部网站,外部网站申请对您的资源进行授权,您是否同意,如下图所示:

点击继续登录后,登录成功,并且返回授权的Token,如下图所示:

 

参见:

http://kazge.com/archives/765.html

http://kazge.com/archives/496.html

Continue reading 【转】Google OAUTH + OpenID解决方案

Pagination


Total views.

© 2013 - 2019. All rights reserved.

Powered by Hydejack v6.6.1