Linux下PhpMyAdmin安裝與安全設定方法

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.zhutiai.com

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模組提供了一個基於規則的(使用Regex分析器的)即時轉向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把它視為反向引用。

Regex的反向引用能力
這是很重要的一點：一旦在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