linux下php教程myadmin安装与安全设置方法
phpmyadmin是一套放在服务器端的通过浏览器界面管理的程序，因此，确保其目录安全性十分重要，否则，将导致数据被盗取甚至遭到恶意破坏。下面将详细讲述一般的防范措施。
所谓的phpmyadmin简单的说就是一种mysql教程的管理工具。
透过此一程式，可以直接从web上去管理mysql，不需要到系统上去执行。
安装步骤：
1.取得档案ftp://ohaha.ks.edu.tw/pub/source/php/phpmyadmin_2.0.5.tar.gz或是
ftp: //ohaha.ks.edu.tw/pub/source/php/c_phpmyadmin_2.0.5.tar.gz
其中唯一的差别是在於後者不需要再做中文最佳化的动作。
所谓的中文最佳化乃是因为此程式的翻译者可能是大陆的..所以翻译不佳
若你觉得没有关的话，也可以忽略它。
2.我们先采用前者然後再加上中文最佳化。
3.将此档解压缩到web伺服器的文件根目录
说明白些也就是你放置网页的地方啦
ex:/usr/local/apache/htdocs/ (这是我网页存放的位置)
a. # mv phpmyadmin_2.0.5.tar.gz /usr/local/apache/htdocs/ 移到文件的根目录
b. # tar zxvf phpmyadmin_2.0.5.tar.gz 解压缩phpmyadmin_2.0.5.tar.gz
c. 路径 /usr/local/apache/htdocs/phpmyadmin
d. 修改设定档
# vi config.inc.php3
找到下面的部分
$cfgservers[1]['host'] = 'localhost'; // mysql 的hostname
$cfgservers[1]['port'] = ''; // mysql 的port 空白表示预设3306
$cfgservers[1]['adv_auth'] = true; // 是否采用进阶功能
$cfgservers[1]['stduser'] = 'root'; // mysql的管理者
$cfgservers[1]['stdpass'] = '123456'; // mysql管理者的密码
//我采用root为管理者,密码为123456 你可以采用自己喜欢的
下面为phpmyadmin 在linux平台安装配置方法
一、 修改phpmyadmin目录名：
在不修改目录名前，其他人很容易洞察该目录名，造成安全隐患。如，假设一台linux主机的域名为：www.test.com，那么不修改目录名的情况下，在地址栏中输入：www.test.com/phpmyadmin/ 就将进入phpmyadmin管理程序。因此如果将phpmyadmin目录改名为一个别人不易知道的目录，如mynameadmin，这样，你在管理自己的数据库教程时，只要键入：www.test.com/mynameadmin/ 就可以通过浏览器管理数据库了。（注：下面仍将使用phpmyadmin目录名，如果目录名已换，只需把phpmyadmin改名为新的目录名即可。）
二、 对phpmyadmin目录加用户身份验证：
这是很多网站需要用户验证时普遍使用的方法，这样当用户第一次浏览进入该目录时，都将出现一个提示窗口，提示用户输入用户名和密码验证，其是通过使用apache server的标准 mod_auth模块实现的，具体操作方法如下：
1、vi编辑apache server配置文件，确保文件中如下两句话没有加注释，如果这两句话前有"#"符号，去掉"#"号。
documentroot /data/web/apache/public/htdocs
accessfilename . htaccess
alloerride all
2、passwd程序创建用户文件：
htpasswd - c /data/web/apache/secrects/.htpasswd 88998
其中，-c表示选项告诉htpasswd你想生成一个新的用户文件，/data/web/apache/secrects/ 是你想存放 .htpasswd 文件的目录，文件名称为 .htpasswd，88998 是在验证时所用到的用户名，敲如以上命令后，系统提示你输入密码，这个密码就是验证时所需要用到的密码，该密码在 .htpasswd 文件中是加密的。现在用more来查看 /data/web/apache/secrects/.htpasswd文件，可以看到其中有一行用户名和一串加密密码。
3、创建 .htaccess 文件：
使用文本编辑器，在目录 phpmyadmin （如果已经改名，就是新的目录名）下创建 .htaccess 文件，在文件中加入如下语句：
authname "用户验证"
authtype basic
authuserfile /data/web/apache/public/htdocs/phpmyadmin/.htpasswd
require user 88998
保存所做操作后，再去看phpmyadmin目录，将提示验证窗口，输入刚用 htpasswd 命令创建的用户名和密码，即可进入该目录。
三、 增加基于主机的访问控制：
在修改了目录名和增加访问验证机制后，应该说现在的phpmyadmin已经很安全了，但由于phpmyadmin目录一般只是数据库管理员使用，为防止别人还知道目录名称和验证密码，还可以增加如下的基于主机的访问控制，基于主机的访问是通过验证用户机器ip来实现的，即只有符合条件的ip才可以反问该目录，否则拒绝访问。
修改 .htaccess 文件如下：
authname "用户验证"
authtype basic
authuserfile /data/web/apache/public/htdocs/phpmyadmin/.htpasswd
require user 88998
order deny,allow
deny from all
allow from 202.100.222.80
这里增加了三条基于主机访问控制指令，其中第一条 order 指令的值是由一个逗号隔开的名单，这个名单表明了哪一个指令更高的优先权，第二条指令 deny 定义不能访问该目录的主机，第三条指令 allow 定义可以访问该目录的主机，这样，该目录除了ip地址为 202.100.222.80 的机器可以访问该目录之外，其他的都不能访问，读者可以把该地址该为用户数据库管理员ip。
phpmyadmin 在linux环境安装一些问题总结与解决方法
1.下载phpmyadmin，自己想办法拷到/var/www/html下，并解压，开始使用。
http://ip/phpmyadmin测试
cp config.sample.inc.php config/config.inc.php
chmod o+w config/config.inc.php
2.遇到问题一,phpmyadmin无法载入mysql扩展，
笔者解决方法为
yum -y install php-mysql
yum install mysqli
运行了http://www.linuxidc.com/phpmyadmin/scripts/setup.php
能够进入phpmyadmin的登录界面。www.111cn.net
3.遇到问题二,phpmyadmin配置文件现在需要绝密的短语密码(blowfish_secret)
修改config/config.inc.php
'blowfish_secret'用一个任意字符串作为cookie的加密字符串，如果没有加密钥匙,系统会显示"配置文件现在需要绝密的短语密码 (blowfish_secret) "
$cfg['blowfish_secret'] = 'custom'; //custom是自定义的
4.遇到问题三，无法载入 mcrypt 扩展.
笔者解决方法：
yum install libmcrypt
yum install php-mcrypt
总结：在解决这些问题上，网络上的资料都是针对windows系统的，很少有针对linux的，笔者结合仅有的资料经过测试，解决了这些问题，但未应用程序测试，下一步准备测试。
记住在每次修改后，注意重启apache:
service httpd restart
=============================
现在只想编译出mod_rewrite.so模块，在apache中进行加载，下面我们就介绍这个方法。
以fedora操作系统进行举例：
1）首次安装apache，在编译时增加——enable-rewrite选项。
如。/configure ——prefix=/usr/local/apachel ——enable-so ——enable-mods-shared=all ——enable-rewrite ——enable-cache
2）增加mod_rewrite模块
# find . -name mod_rewrite.c //在apache的源码安装目录中寻找mod_rewrite.c文件
# cd path/to/mod_rewrite.c //进入包含mod_rewrite.c文件的目录
# /usr/local/apache/bin/apxs -c mod_rewrite.c //apxs应指定绝对路径，在你当前正在使用apache的bin目录里
# /usr/local/apache/bin/apxs -i -a -n mod_rewrite mod_rewrite.la
如果没有什么错误的话，应该在你的apache的modules目录中编译出一个mod_rewrite.so文件。
编辑httpd.conf文件，确认httpd.conf中已经包含mod_rewrite.so的加载语句，如下：
loadmodule rewrite_module modules/mod_rewrite.so
这时，你的apache应该已经支持rewrite了。
vicos注：完成之后，记得重启服务器apache
更详细的安装教程
mod_rewrite模块提供了一个基于规则的(使用正则表达式分析器的)实时转向url请求的引擎。支持每个规则可以拥有不限数量的规则以及附加条件规则的灵活而且强大的url操作机制。此url操作可以取决于各种测试，比如服务器变量、环境变量、http头、时间标记， 甚至各种格式的用于匹配url组成部分的查找数据库。
mod_rewrite 模块可以操作url的所有部分(包括路径信息部分)， 在服务器级的(httpd.conf)和目录级的(.htaccess)配置都有效，还可以生成最终请求串。此重写操作的结果可以是内部子处理，也可以是外部请求的转向， 甚至还可以是内部代理处理。
但是，所有这些功能和灵活性带来一个问题，那就是复杂性， 因此，不要指望一天之内就能看懂整个模块。
内部处理
mod_rewrite模块的内部处理极为复杂，但是，为了使一般用户避免犯低级错误， 也让管理员能充分利用其功能，在此仍然做一下说明。
api程序段
首先，你必须了解，apache是通过若干程序段来处理http请求的。 apache api 对每个程序段提供了一个hook程序。 mod_rewrite使用两个hook程序： 其一是，url到文件名的转译hook，用在读取http请求之后，而在授权开始之前；其二是，修正hook，用在授权程序段和读取目录级配置文件(.htaccess)之后， 而在内容处理器激活之前。
所以， apache收到一个请求并且确定了响应主机(或者是虚拟主机)之后，重写引擎即开始执行url到文件名程序段，以处理服务器级的配置中所有的mod_rewrite指令。在最终数据目录确定以后，进入修正程序段并触发目录级配置中的mod_rewrite指令。这两个程序段并不是泾渭分明的，但都实施把url重写成新的url或者文件名。 虽然api最初不是为此设计的，但它已经成为api的一种用途，而在apache 1.x 中这是mod_rewrite唯一的实现方法。 记住以下两点，会有助于更好地理解：
虽然 mod_rewrite可以重写url为url，重写url为文件名， 甚至重写文件名为文件名，但是目前api只提供一个url到文件名的hook。在apache 2.0 中，增加了两个丢失hook以使处理过程更清晰。 但是，这样做并没有给用户带来麻烦，只需记住这样一个事实： apache借助url到文件名的hook而比api设计的目标功能更强大。
难以置信的是，mod_rewrite提供了目录级的url操作，即，.htaccess文件， 而这些文件必须在url转换成文件名以后的较多步骤完成之后才会被处理。这也是必须的，因为.htaccess文件存在于文件系统中，所以处理已经到达这个层面。换句话说，根据api程序段，这时再处理任何url操作已经太晚了。 为了解决这个鸡和蛋的问题，mod_rewrite使用了一个技巧：在进行一个目录级的url/文件名的操作时，mod_rewrite先把文件名重写回相应的url (通常这个操作是不可行的，但是参考下面的rewritebase指令就明白它是怎么实现的)，然后，对这个新的url建立一个新的内部的子请求，以此重新开始api程序段的执行。
另外，mod_rewrite尽力使这些复杂的操作对用户全透明，但仍须记住： 服务器级的url操作速度快而且效率高，而目录级的操作由于这个鸡和蛋的问题速度慢效率也低。但从另一个侧面看，这却是mod_rewrite得以为一般用户提供(局部限制的)url操作的唯一方法。
牢记这两点!
规则集的处理
当mod_rewrite 在这两个程序段中开始执行时，它会读取配置结构中的配置好的 (或者是在服务启动时建立的服务器级的，或者是apache核心在遍历目录采集到的目录级的)规则集，随后，启动url重写引擎来处理(带有一个或多个条件)的规则集。无论是服务器级的还是目录级的规则集，都是由同一个url重写引擎处理，只是处理结果不同而已。
规则集中规则的顺序是很重要的，因为重写引擎是按一种特殊的(非常规的)顺序处理的， 其原则是：逐个遍历每个规则(rewriterule directives)，如果出现一个匹配条件的规则，则可能回头遍历已有的规则条件(rewriteconddirectives)。由于历史的原因，条件规则是置前的，所以控制流程略显冗长，细节见figure 1。
figure 1:the control flow through the rewriting ruleset
可见，url首先与每个规则的pattern匹配， 如果匹配不成功，mod_rewrite立即终止此规则的处理，继而处理下一个规则。如果匹配成功，mod_rewrite寻找响应的规则条件，如果一个条件都没有，则简单地用substitution构造的新的值来替换url，然后继续处理其他规则。 如果条件存在，则开始一个内部循环按其列出的顺序逐个处理。对规则的条件的处理有所不同：url并不与pattern匹配，而是，首先通过扩展变量、反向引用、查找映射表等步骤建立一个teststring的字符串，随后，用它来与condpattern匹配。如果匹配不成功，则整个条件集和对应的规则失败； 如果匹配成功，则执行下一个规则直到所有条件执行完毕。如果所有条件得以匹配，则以substitution替换url，并且继续处理。
特殊字符的引用
在apache 1.3.20, teststring anｄ substitution 字符串中的特殊字符可以用前缀的斜杠来实现转义(即，忽略其特殊含义而视之为普通字符)。比如，substitution可以用'$'来包含一个美元符号， 以避免mod_rewrite把它视为反向引用。
正则表达式的反向引用能力
这是很重要的一点：一旦在pattern或者condpattern使用了圆括号， 就会建立内部的反向引用，可以使用$n和%n来调用(见下述)，并且，在substitution和teststring中都有效。 figure 2 说明了反向引用被转换扩展的位置。
figure 2: the back-reference flow through a rule.
虽然mod_rewrite内部处理的这个过程是比较杂乱的， 但是了解这些可以帮助你阅读下文中指令的讲述。
环境变量
mod_rewrite 模块会跟踪两个额外的(非标准的)cgi/ssi环境变量， script_url和script_uri。 他们包含了当前资源的逻辑的网络状态, 而标准的cgi/ssi变量script_name和 script_filename包含的是物理的系统状态。
注意: 这些变量保持的是其最初被请求时的uri/url, 即, 在任何重写操作之前的。 其重要性在于他们是重写操作重写url到物理路径名的原始依据。
举例
script_name=/sw/lib/w3s/tree/global/u/rse/.www/index.html
script_filename=/u/rse/.www/index.html
script_url=/u/rse/
script_uri=http://en1.engelschall.com/u/rse/
实用方案
我们还提供另外一个文档url rewriting guide， 列举了许多基于url的问题的实用方案，其中你可以找到真实有用的规则集和mod_rewrite的更多信息。
rewritebase 指令
rewritebase 指令显式地设置了目录级重写的基准url。 在下文中，你可以看见rewriterule可以用于目录级的配置文件中(.htaccess)，并在局部范围内起作用，即，规则实际处理的只是剥离了本地路径前缀的一部分。 处理结束后，这个路径会被自动地附着回去。默认值是，rewritebase physical-directory-path
在对一个新的url进行替换时， mod_rewrite模块必须把这个url重新注入到服务器处理中。为此，它必须知道其对应的url前缀或者说url基准。通常，此前缀就是对应的文件路径。但是，大多数网站url不是直接对应于其物理文件路径的，因而一般不能做这样的假定! 所以在这种情况下，就必须用rewritebase指令来指定正确的url前缀。
如果你的网站服务器url不是与物理文件路径直接对应的， 而又需要使用rewriterule指令， 则必须在每个对应的.htaccess文件中指定rewritebase。
举例，目录级配置文件内容如下:
#
# /abc/def/.htaccess -- per-dir config file for directory /abc/def
# remember: /abc/def is the physical path of /xyz, i.e., the server
# has a 'alias /xyz /abc/def' directive e.g.
#
rewriteengine on
# let the server know that we were reached via /xyz anｄ not
# via the physical path prefix /abc/def
rewritebase /xyz
# now the rewriting rules
rewriterule ^oldstuff.html$ newstuff.html
上述例子中，对/xyz/oldstuff.html 的请求被正确地重写为物理的文件/abc/def/newstuff.html.
for apache hackers
以下列出了内部处理的详细步骤:
request:
/xyz/oldstuff.html
internal processing:
/xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server alias)
/abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir rewriterule)
/abc/def/newstuff.html -> /xyz/newstuff.html (per-dir rewritebase)
/xyz/newstuff.html -> /abc/def/newstuff.html (per-server alias)
result:
/abc/def/newstuff.html
虽然这个过程看来很繁复，但是由于目录级重写的到来时机已经太晚了，它不得不把这个(重写)请求重新注入到apache核心中，所以apache内部确实是这样处理的。但是：它的开销并不象看起来的那样大，因为重新注入完全在apache服务器内部进行， 而且这样的过程在apache内部也为其他许多操作所使用。所以，你可以充分信任其设计和实现是正确的。
rewritecond 指令
rewritecond指令定义了一个规则的条件，即，在一个rewriterule指令之前有一个或多个rewritecond指令。 条件之后的重写规则仅在当前uri与pattern匹配并且符合这些条件的时候才会起作用。
teststring是一个纯文本的字符串，但是还可以包含下列可扩展的成分：
rewriterule反向引用: 引用方法是
$n