2011-03-21
发表者 Venus
暂无评论
# mysql -u root -p //默认无密码，登陆数据库
# mysql> use mysql; //使用mysql数据库
#
# mysql> update user set password=PASSWORD(‘newpassword’) where user=’root’;
//更新密码
#
# mysql> flush privileges; //刷新MySQL系统权限的相关表 也可以理解为刷新缓存
#
# mysql> exit
看见 行匹配 和更改为3说明成功。
之前用的mysqladmin方式更改密码的缺点是：
仅能更改一行记录。这样会导致 root用户在 mysql 表里的3行（localhost {HOSTNAME} 127.0.0.1）记录有不同的密码，会对以后使用root用户操作带来隐患。
2011-03-21
发表者 Venus
暂无评论
有位同学的apache基本一天挂一次，重启httpd服务后正常。检查日志发现一个错误并且是经常性出现：child process * still did not exit, sending a SIGTERM
猜测问题应该出现在子进程中的MaxRequestsPerChild部分，检查他的工作方式：apachectl -l
是prefork模式，然后检查他的配置文件，发现MaxRequestsPerChild部分参数为0，想到有可能是内存泄露了。
对于他这个问题，继续跟进。淡定···
将MaxRequestsPerChild设置成非零值有两个好处：
可以防止(偶然的)内存泄漏无限进行，从而耗尽内存。
给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。
今天问题算是解决了：
发现日志说，写入访问日志或者是错误日志意外失败。
df -h 一看/var/logs 使用率已经100%了。那么再次检查httpd.conf文件，确定服务器上挂载的20多个站日志位置都位于此路径下，导致日志无法写入而系统崩溃。
通知它删减日志，运行看看。继续跟进···
过了好几天了，没听见他再反应服务器崩溃，那么可以确定，问题解决了。
2011-03-18
发表者 Venus
暂无评论
为了的到mcrypt.so库文件，先后安装编译了mhash和libmcrypt，但是到最后编译mcrypt时报错：
configure: error: *** libmcrypt was not found
最后发现是因为环境变量的问题，gcc编译的时候根据自身定义的变量寻找相关函数库等文件，libmcrypt也是刚安装的，在变量中没有定义出来，所以手动添加：
[root@localhost modules]# export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
再次编译即可。
或者执行一下ldconfig貌似也可以。
2011-03-18
发表者 Venus
暂无评论
搜集相关资料说明的原因是phpmyadmin不允许在权限为777模式下运行。（777一般是当初为了测试才设置的，结果给出问题了。）
解决办法：
chcon -R 755 phpmyadmin
OK！
2011-03-17
发表者 Venus
暂无评论
PHP实现多web服务器共享SESSION数据(session数据写入mysql数据库)
一、问题起源
稍大一些的网站，通常都会有好几个服务器，每个服务器运行着不同功能的模块，使用不同的二级域名，而一个整体性强的网站，用户系统是统一的，即一套用户名、密码在整个网站的各个模块中都是可以登录使用的。各个服务器共享用户数据是比较容易实现的，只需要在后端放个数据库服务器，各个服务器通过统一接口对用户数据进行访问即可。但还存在一个问题，就是用户在这个服务器登录之后，进入另一个服务器的别的模块时，仍然需要重新登录，这就是一次登录，全部通行的问题，映射到技术上，其实就是各个服务器之间如何实现共享 SESSION 数据的问题。
二、PHP SESSION 的工作原理
在解决问题之前，先来了解一下 PHP SESSION 的工作原理。在客户端(如浏览器)登录网站时，被访问的 PHP 页面可以使用 session_start() 打开 SESSION，这样就会产生客户端的唯一标识 SESSION ID(此 ID 可通过函数 session_id() 获取/设置)。SESSION ID 可以通过两种方式保留在客户端，使得请求不同的页面时，PHP 程序可以获知客户端的 SESSION ID;一种是将 SESSION ID 自动加入到 GET 的 URL 中(这个只能在unix系统下能实现，windows系统不能实现自动加入url中)，或者 POST 的表单中，默认情况下，变量名为 PHPSESSID;另一种是通过 COOKIE，将 SESSION ID 保存在 COOKIE 中，默认情况下，这个 COOKIE 的名字为 PHPSESSID。这里我们主要以 COOKIE 方式进行说明，因为应用比较广泛。
那么 SESSION 的数据保存在哪里呢?当然是在服务器端，但不是保存在内存中，而是保存在文件或数据库中。默认情况下，php.ini 中设置的 SESSION 保存方式是
files(session.save_handler = files)，即使用读写文件的方式保存 SESSION 数据，而 SESSION 文件保存的目录由 session.save_path 指定，文件名以
sess_ 为前缀，后跟 SESSION ID，如：sess_c72665af28a8b14c0fe11afe3b59b51b。文件中的数据即是序列化之后的 SESSION 数据了。如果访问量大，可能产生的
SESSION 文件会比较多，这时可以设置分级目录进行 SESSION 文件的保存，效率会提高很多，设置方法为：session.save_path=”N;/save_path”，N 为分级的级数
，save_path 为开始目录。当写入 SESSION 数据的时候，PHP 会获取到客户端的 SESSION_ID，然后根据这个 SESSION ID 到指定的 SESSION 文件保存目录中找到
相应的 SESSION 文件，不存在则创建之，最后将数据序列化之后写入文件。读取 SESSION 数据是也是类似的操作流程，对读出来的数据需要进行解序列化，生成相应
的 SESSION 变量。
三、多服务器共享SESSION 的主要障碍及解决办法
通过了解 SESSION 的工作原理，我们可以发现，在默认情况下，各个服务器会各自分别对同一个客户端产生SESSION ID，如对于同一个用户浏览器，A 服务器产生的 SESSION ID 是 30de1e9de3192ba6ce2992d27a1b6a0a，而 B 服务器生成的则是c72665af28a8b14c0fe11afe3b59b51b。另外，PHP 的 SESSION 数据都是分别保存在本服务器的文件系统中。
确定了问题所在之后，就可以着手进行解决了。想要共享 SESSION 数据，那就必须实现两个目标：
一个是各个服务器对同一个客户端产生的 SESSION ID 必须相同，并且可通过同一个 COOKIE 进行传递，也就是说各个服务器必须可以读取同一个名为 PHPSESSID 的 COOKIE;
另一个是 SESSION 数据的存储方式/位置必须保证各个服务器都能够访问到。 简单地说就是多服务器共享客户端的 SESSION ID，同时还必须共享服务器端的SESSION数据。
第一个目标的实现其实很简单，只需要对 COOKIE 的域(domain)进行特殊地设置即可，默认情况下，COOKIE 的域是当前服务器的域名/IP 地址，而域不同的话，各个服务器所设置的 COOKIE 是不能相互访问的。