Entries Tagged as 'Php'

php-java-bridge-5 isn’t available on rhel5!?

php-java-bridge是一个在php和java程序中互相调用的东东
前段时间接开发需求
在rhel5的机器(redhat enterprise linux advance server 5 update 1)上装这么个东东
因为开发需要在php程序里调java的包
于是就去其官网php-java-bridge.sourceforge.net下了个最新版php-java-bridge_5.3.2.1.2.tar.gz
然后安装之

tar xzvf php-java-bridge_5.3.2.1.2.tar.gz
cd php-java-bridge-5.3.2.1.2
/usr/bin/phpize
./configure –with-java=/usr/java/default
make
. install.sh

安装的时候选”no”(没有单独的后台程序服务于java)
装完后
service httpd restart(重起apache)
javaenabled且状态是running
但实际程序一跑就出错
怎么改都不行
当程序里有”java_require”的时候出错

PHP Fatal error: Call to undefined function java_require() in

而且跑php-java-bridge带的测试程序test.php都出错:

protocol error: , Invalid document end at col 1. Check the back end log for details.PHP Notice: fwrite(): send of 11 bytes failed with errno=32 Broken pipe in /usr/share/pear/java/Java.inc on line 838
java.lang.RuntimeException: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:15596 accept,resolve)
at php.java.bridge.JavaBridge.init(JavaBridge.java:327)
at php.java.bridge.Standalone.init(Standalone.java:211)
at php.java.bridge.Standalone.main(Standalone.java:279)
Caused by: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:15596 accept,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkAccept(SecurityManager.java:1157)
at java.net.ServerSocket.implAccept(ServerSocket.java:457)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at php.java.bridge.TCPServerSocket.accept(TCPServerSocket.java:89)
at php.java.bridge.JavaBridge.init(JavaBridge.java:309)
… 2 more
Exception in thread “main” java.lang.SecurityException: exitVM disabled by JavaBridgeSecurityManager.java
at php.java.bridge.JavaBridgeSecurityManager.checkExit(JavaBridgeSecurityManager.java:104)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:906)
at php.java.bridge.Standalone.main(Standalone.java:282)

而且发现网上也很少有人说装php-java-bridge5的
于是想想会不会是版本问题
于是又下了个php-java-bridge4的包php-java-bridge_4.3.3.tar.gz
重新安装

tar xzvf php-java-bridge_4.3.3.tar.gz
cd php-java-bridge-4.3.3
/usr/bin/phpize
./configure –with-java=/usr/java/default
make
. install.sh
/etc/rc.d/init.d/httpd restart

这下再试就没有问题了

install php(<5.2.0) extension json on rhel as5

一台rhel as5 update2的机器
php版本是5.1.6
需要安装json(一种php扩展)
php从5.2.0开始就已经将json集成到core代码里
所以5.2.0及以后的php是不需要单装json的
但我们这里是5.1.6的php
看了下文档
就是一句:

pecl install json

最后会出错:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 7680 bytes) in /usr/share/pear/PEAR/PackageFile/v2.php on line 1067

忽略这个错误
php -m
发现还没有json
编辑/etc/php.ini
加上一句

extension=json.so

重起apache
搞定
猜想可能是最后改配置文件php.ini的时候出错了,于是没有更新php.ini
导致需要手工更改

fc3下安装php5.2.5+pdo_mysql

也算是需求推动
产品那边需要在一台fc3(fedora core 3)的机器上装上php5
并且要启用pdo_mysql支持
偶,额滴神呀
幸好以前在别的机器上手工编过php5.x(具体版本5.2.5)
赶紧从那台机器上把php5.2.5拷过来
并把原来的./configure连同编译参数都调出来
再加上个–with-pdo-mysql重新configure一下
再make
make的时候出错了
不知道原因在哪儿
后来在网上搜了下
找了种折衷的办法
说是先编好php5
然后再把pdo_mysql的支持编进去

cd php5.2.5/ext/pdo_mysql
phpize
./configure
make
make install

这样居然成功了
再接着改php.ini
把编出来的pdo_mysql.so正确load进来
这样居然成功了!!

一台机器php连mysql出client版本不支持的问题

在控制台上直接执行php test.php
系统出错:
“PHP Warning: mysql_connect(): Client does not support authentication protocol requested by server”
于是就在本机控制台用命令
mysql -h 192.168.1.1 -u user -p
(这里192.168.1.1是mysql服务器ip)
再输入密码来连
这样没有问题
然后在192.168.1.1把程序拷过去
直接执行
然后又没有问题
当时就有点困惑了
这两台机器一样的php-mysql版本呀
一样的mysqlclient版本呀
可为什么一个能连一个出错呢
要说对client那台机器的权限有限制
但是在client那台机器上直接用mysql客户端程序也能连呀
于是
似乎陷入困境
mysql官网对这个错误的解释是老板本的mysql和新版本的mysql的密码格式不兼容
如果用老板本的mysql client去连新版本的mysql server
如果mysql server上的密码格式是新格式的话
就会出这个错误
显然,本例就是这样

最后问题解决后
才发现其实一开始分析问题的时候就出现了偏差
其实知道问题的原因是由于client的版本和server上存储密码的格式相关
那么就应该去确认这两台机器一台连不上一台没问题他们分别的client版本和server上的密码格式的
如果是这样
一开始就去服务器端
use mysql
select * from user where User = ‘user’;
一看就知道了
原来有条记录
Host正好是client的ip
client连过来的时候正好是匹配这条记录
但是其密码格式是新格式
而client上的mysql client版本是老板本
不出问题才怪呢!!
再看看从服务器上通过连为什么又没有问题呢
原来还有条记录
Host是’192.168.1.%’
他的密码格式是老格式的
服务器上连过来的时候正好是匹配这一条记录
自然OK

这样解决起来也就容易了
直接将写着client ip的那条记录删掉就好了

php连mysql的诡异问题:“MySQL server has gone away”

今天写了个小程序
用来监测某些机器上的某些进程是否存在
需要从mysql中查出ip和进程字串
然后从中控上一台一台ssh上去ps查进程是否存在
如果状态变化(原来标记不存在的现在有了,或是原来标记存在的现在没有了)
还需要更新mysql库中的相应状态字段
因为查询出来的数据比较多(600多条)
而且我还要一台一台ssh上机器检测进程
等我发现某台机器的某个进程状态改变要update库的时候
数据库报错:

MySQL server has gone away

查了好些资料
也没找出原因来
最后按照文档上建议的
先判断
然后再执行mysql_query

function connect(){
$db = mysql_connect(’xxx.xxx.xxx.xxx’, ‘xxx’, ‘xxxxxx’);
mysql_select_db(’db1′);
return $db;
}
if (!$db){
mysql_close($db);
$db = connect();
}elseif(!mysql_ping($db)){
mysql_close($db);
$db = connect();
}
mysql_query(”$sql”);

不管怎么样
这个问题算是解决了
不过说实话:为什么我还是没搞明白
:)

for cacti0.8.7b的cacti-plguin-arch 2.0的bug?

今天升级cacti0.8.7a版到0.8.7b
但是关键升级cacti plugin architecture的时候有些波折
按照文档升级完了
页面老不对
主要是内部的一些链接不对
查了半天
发现是url_path的问题
include/plugins.php里有一句:

$config['url_path'] = substr(__FILE__, strlen($_SERVER['DOCUMENT_ROOT']), strlen(__FILE__) - strlen($_SERVER['DOCUMENT_ROOT']) - strlen(’include/plugins.php’));

应该是来算url_path
但是就是这句算的url_path不对
我的cacti在/cacti/下
关键是我的incluce/plugins.php绝对路径里有soft link
然后web目录下又是Alias
所以不管怎么样
这句算出来的url_path不对
最后没办法(php我也不是很精通)
直接把这句注释掉
写死url_path为正确值了事

$config['url_path'] = ‘/cacti/’;

一台机器load高的问题

从春节过后上班就一直在搞这台load比较高的机器
这台机器上跑的是apache+mod_ssl
最早以为是mod_ssl造成的load过高
于是把网通和教育网前端proxy转过来的请求都指给了http
(原来是https的请求指向https;http的请求指向http)
心想:少了至少一半的https请求,load该下来了吧
结果是: load还是居高不下
于是我又只有老老实实的查
查access_log,看看都访问了些什么东西
发现有个php程序是算某个文件的内容的md5码的
请求数巨多
于是我就打开看了看
发现是用函数md5_file来算的
我一翻php文档
发现这个函数速度巨慢,php文档建议用系统命令”openssl md5″来代替
我用测试程序测了下
发现用md5_file用的时间是openssl md5方法的70倍!!!

发现这个问题后
我欣喜若狂
总觉得应该已经找到问题之所在了
可当调整了程序之后,发现:
load还是没有降下去 :(

这下似乎陷入僵局了
期间我把ipv6 disable了,重起过机器,对降低load还是没有效果

我再仔细分析了系统情况
发现系统网络流量也不大、cpu也不是特别忙(50%左右的idle)、内存也还有富裕
唯一的问题就是cpu的iowait比较高,一般在40%~50%之间
那么看起来应该是系统硬盘io的问题咯
这台机器的应用倒是在不停的upload、download一些文件
磁盘io多是正常的
但是用高速scsi硬盘做了raid(应该是raid5)的设备上再做reiserfs系统的磁盘设备会是性能瓶颈?
听起来自己都不相信
于是用iostat 5来看
发现一个设备一般情况下每秒钟的时候有3000左右个block的写入
但是想想,一个block只有4k,那么一秒钟12M的写入,会造成性能瓶颈?不知道。

再用vmstat 5来看
发现io的bo一项经常有超过2000的数
按照某人的说法
当小文件随机写的数大于2000的时候
有性能问题
这台机器貌似就正是这个情况(小文件随机写)

大概齐知道问题所在硬盘读写之后
既然暂时改不了程序的话
那就想办法调优reiserfs

最后的结果是给mount reiserfs分区的时候加了一堆参数了事
参数是这样的:

defaults,noatime,nodiratime,notail,data=writeback

改php.ini使得php5兼容php4

今天
公司一同事告诉我需要把某两台机器的php换成php4
因为要在上面跑的某种软件是用php4写的
而且用了n多php5不支持的php4独特的写法
//咣当
我马上就有“以头抢地”的冲动了
这台机器可是我辛辛苦苦从fc3在线upgrade到fc4
再从fc4在线upgrade到fc5的呀!
5555555555555555
要php4的话为什么当时需求里没明确呢
唉,估计他们当时也不知道一定要php4
其实重编个php4也不难
只是,……
以后维护起来会相对会比较麻烦
其实最主要的还是我自己有倒坎坎:尽量使用官方发布的rpm包
于是我给了他2条建议:
1,下单让运维部门的人重装成fc3
2,内部找fc3的机器换一下
其实我的建议也是行得通的(当时我也不知道其实有更简单的解决方法)
重装也就20分钟左右的事情;而且内部也还是有很多的fc3的机器的
但别人马上就否了
说没法换,也不能重装
理由是烤了好多的软件上去了
我晕,不是都还没上线吗?没上线自己把服务再倒一倒也不是什么大事儿呀
……:(
扯远了
扯得跟技术没什么关系了
写这么多废话在这里只是想说明做support工作是多么的……
我这还是内部的support呢
如果是对外的话
nnd那可更难以想象咯

言归正传
后来一看php.ini文件,里面有一段是这么说的:

; Enable compatibility mode with Zend Engine 1 (PHP 4.x)
zend.ze1_compatibility_mode = Off

于是
我们就打开zend.ze1_compatibility_mode,像这样:

zend.ze1_compatibility_mode = On

重起apache
居然就搞定了

cacti+thold插件实现监控硬盘分区使用百分率情况

老大说要监控机器的硬盘分区的使用情况
大于一定比率要报警
知道cacti + thold插件可以做这个
于是就装plug architecture、settings(plugin)
(这两个是thold插件所依赖的,所以要先装)
然后再装thold插件
这都简单
关键是算使用百分比的CDEFs
准确算法应该是:CURRENT_DATA_SOURCE * 100 / hdd_total
但现在的问题是这里不能得到hdd_total的值
于是看了看thold3.8的代码
发现其实在plugin thold 3.8的版本里
已经取好了data source item “hdd_total”的值为special data source:VALUE_OF_HDD_TOTAL
所以只要在定义CDEFs的时候,把最后的字串等于

CURRENT_DATA_SOURCE,VALUE_OF_HDD_TOTAL,/,100,*

于是具体方法就简单了
直接用custom string即可
或者更王道一点的办法是改global_arrays.php
在$custom_data_source_types加上对”VALUE_OF_HDD_TOTAL”的描述
这样设CDEFs的时候就可以在下拉列表框里选择了

upgrade cacti from 0.8.6k to 0.8.7

以前为了解决cact的一个bug(详细情况看这里)
把系统升级到了当时最新的0.8.6-svn
其中的版本就是0.8.6k
现如今cacti的最新的stable版本都已经是0.8.7了
于是我也想升级
当我当下来0.8.7的文件
升级的时候,发现系统报不支持从0.8.6k升级到0.8.7
查了查升级脚本,果然是没有对0.8.6k的支持
于是就求助于cacti的官方论坛
很快有了答案
于是照着做:
1,停掉apache
2,停掉Cron(啊!?这步我没做!!!)
3,备份mysql库
4,取回0.8.7的包,包含patches(我是从这里取了patch回来,不知道对不对)
5,编辑文件install/0_8_6j_to_0_8_7.php,把在其中注释为“Add 1 min rra”的这段程序注释掉
6,在mysql里,执行”

update version set cacti=’0.8.6j’ where cacti=’0.8.6k’

“(其实还要先用use命令进入cacti所用的数据库)
7,把原来0.8.6k的include/config.php拷贝过来到include/config.php
8,把apache起起来
9,通过浏览器访问cacti系统
10,根据提示升级,碰到sql语句执行失败手工确认(因为0.8.6k和0.8.6j的数据库结构还是有变化的,这里等于是强制把0.8.6k当作0.8.6j来往0.8.7上升级,有错基本上是正常的)
11,如果没有问题,再把Cron打开

我照着做了
基本上解决了问题
只有一点:升级完成后,貌似所有的图都给删掉了然后重建的,所以以前的数据图上就显示不出来了
这也许是我没有按回帖里写的那样先停掉Cron最后再启动的原因吧