为IT服务 [龙飞的博客]

今天看见篇新闻说关停未提交实名信息的cn域名开始关闭的时候想检查下自己的cn域名的，结果发现竟然过期了。。。。
以防万一如果发现226617.cn无法打开的时候可以用226617.com来访问本博客

根据我以前的测试 Ext4 的性能好过 Ext3,在 RHEL5 上的 2.6.18-110 也有加入 Ext4 了。但默认没有让我们使用，怎么样才能不重起，能使用这个啦。
其实我们只要加入一个包e4fsprogs 就行，它其实和 e2fsprogs 是一样的功能，这 RHEL-6 中，会变成一个默认的包的。所以我们目前还只能使用这个包来调整和设置Ext4.

yum -y install e4fsprogs

在 RHEL 和 Centos5 中使用 Ext4 前，很多想可能想先给现有的文件系统转换成 Ext4 ，只要运行下面的命令就行了

tune4fs -O extents,uninit_bg,dir_index,flex_bg /dev/sdb1

在重起前，我还要让内核支持 Ext4 的文件系统，需要修改 initrd 的文件本身的内容。如下命令来生成 支持 Ext4 的 initrd。

mkinitrd --with=ext4 --with=ext3 -f /boot/initrd-2.6.18-194.8.1.el5.img 2.6.18-194.8.1

转载自：扶凯[http://www.php-oa.com]

open_basedir是php提升安全性的重要功能，eaccelerator是提速php的扩展模块，但是似乎默认环境下他们2一起用只要有require就会造成大量的php错误。


PHP Warning: Unknown: open_basedir restriction in effect. File() is not within the allowed path(s): (/www/:/tmp/) in Unknown on line 0


要解决这个问题的话在编译eaccelerator时 加上一个参数就行 –without-eaccelerator-use-inode
官方也说将在0.9.6.1的下一个release中默认启用这个参数。

这次的nginx漏洞可谓是惊天，具体就不说了，详情见 http://www.80sec.com/nginx-securit.html
这漏洞可怕之处就是一旦有用户可以上传的地方如果能把php改后缀方式上传到服务器的话，就能任意执行。
其实有一个通用的方法可以来避免这种未知漏洞，就是禁止用户上传目录执行php权限。
在apache下面我们可以通过：

1
2
3

   <Directory /website/attachments>
        php_flag engine off
   </Directory>

的方式来来禁用目录下文件php执行权限。
那么在nginx里面同样可以实现这种方法，那就是location的优先匹配，关于location可以参考我之前的一批文章http://226617.cn/archives/392.htm
这里简单就举个例子

1
2
3
4

   location ^~ /attachments/
   {
      access_log  off;
   }

这样 attachments这个目录 就不会再去跳转给fastcgi去执行php了

最近再做个mysql一从多主的配置，需要在一台机器上安装多个mysql。
起先是按照复制了多了mysql 同时起，在琢磨如何做启动脚本的时候发现support-files目录下有个mysqld_multi.server文件，一查发现原来是现成的多实例管理工具。
首先得新建个data目录给新的实例，可以把原来的data目录复制个新的 只需要mysql库，也可以用工具部属个

1

./scripts/mysql_install_db --basedir=/usr/local/mysql3307 --datadir=/mysql/mysql3307/data --user=mysql

然后修改下my.cnf
主要增加

1
2
3
4
5
6

[mysqld_multi]
mysqld = /usr/local/mysql/bin/mysqld_safe
mysqladmin = /usr/local/mysql/bin/mysqladmin
user = shutdown
password = 123456
log = /mysql/mysqld_multi.log

然后把原来的 [mysqld] 改为 [mysqld1]
在新增新的实例配置

1
2
3
4
5
6

[mysqld2]
port = 3307
socket = /tmp/mysql3307.sock
datadir = /storage/mysql/data3307
............
............

然后把 mysqld_multi.server 做成启动服务

1
2
3
4
5
6

cp ./support-files/mysqld_multi.server /etc/rc.d/init.d/mysqld
chown root:root /etc/rc.d/init.d/mysqld
chmod 755 /etc/rc.d/init.d/mysqld
chkconfig --add mysqld
chkconfig --level 3 mysqld on
chkconfig --level 5 mysqld on

启动和关闭全部mysql实例
启动：service mysqld start
关闭：service mysqld stop

对单台数据库的启动和关闭
启动： service mysqld start 1
关闭： service mysqld stop 1

也可以同时启动和关闭多个数据库实例
启动： service mysqld start 1-2
关闭： service mysqld stop 1-2

如果启动的时候提示出错信息：
WARNING: my_print_defaults command not found.
Please make sure you have this command available and
in your path. The command is available from the latest
MySQL distribution.
ABORT: Can’t find command ‘my_print_defaults’.
This command is available from the latest MySQL
distribution. Please make sure you have the command
in your PATH.

先添加
export PATH=/usr/local/mysql/bin:$PATH
然后在启动mysql

VirtualBox的虚拟机克隆主要就是克隆一份vdi文件，今天在克隆一台VirtualBox的虚拟机时以为和vmware那样复制粘贴注册vdi的时候会提示copy it之类的，没想到直接报错uuid重复注册。翻了下帮助原来VirtualBox有转码的工具来进行vdi克隆。
在VirtualBox的安装目录下有个 VBoxManage.exe 其实这工具有蛮多功能，有兴趣的同学可以自己看看帮助。我们这里就说下如何克隆vdi了：
VBoxManage.exe clonevdi 原始VDI文件名 新的VDI文件名
其实蛮方便的一个工具想不懂为啥不做成图形的非得要敲命令呢，用户体验真差。

今天在装sphinx，收尾准备做个增量的脚本放crontab里面去，结果每次执行都是提示: No such file or directory。搞来搞去最后发现文本格式忘了改成unix的了，汗

今天在准备部署一台新的虚拟机，把模板机更新了下补丁，装了新的vmtools，克隆的时候再快结束的时候提示虚拟机文件损坏。由于模板机能正常开机运行，虚拟机内操作也很正常，所以觉得和vmdk文件没什么关系，而且克隆的时候vmdk也是克隆完成的，所以怀疑是vmx文件的问题，于是下载了下来仔细看了下，发现一个可疑之处 uuid.location = “” 内容竟然空白，又对比了一台正常的机器和一台刚刚克隆完的机器，证实确实是uuid.location问题，把uuid.location = “” 这行删除掉，上传上esx，重新启动模板机后就自动生成了。然后克隆成功，问题解决。

有个mysql的查询 用的 where xxx in ('a','b','c','d')，现在有一批数据需要放入in () 来查询，在想如何批量转换成'a','b','c','d' 这样的格式。
首先我把数据处理成每行1个的格式：
a
b
c
d
这样
通过EditPlus的正则替换功能，查找^.* 替换为 '\0' 得到
'a'
'b'
'c'
'd'
然后在通过正则替换，查找 \n 替换为 , 就得到了
'a','b','c','d'
达到目标

今天忽然发现VC里某台ESX里面的虚拟机全部无法控制，列表里面CPU和内存信息都是0，显然这台ESX出问题了，尝试断开并重新连接这台ESX结果连接失败，弹出输入用户名和密码，填写后还是连接不上，尝试ping这台esx主机发现ping的通，直接登录到esx的console发现能登陆，检查服务也正常。看来是esx的问题了，打算重启下，可以里面有2台比较重要的虚拟机，直接重启ESX担心会造成影响，所以尝试的重启部分服务，结果service mgmt-vmware restart后正常了。

一般情况下出现esx和vc的连接问题除了重启上面的mgmt-vmware外还可以service vmware-vpxa restart重启下vpxa，说不定就能解决