java和jsvc哪個好,java和js有什麼區別

本文目錄一覽：

• 1、如何利用Jsvc把Java程序嵌入到Linux服務中
• 2、jsvc和直接運行java的區別
• 3、tomcat jsvc是什麼
• 4、Tomcat篇02-整體架構和I/O模型
• 5、linux tomcat 日誌 catalina.out沒有，日誌裏面沒一個文件。
• 6、有Hadoop使用kerberos認證經驗的大神沒有

如何利用Jsvc把Java程序嵌入到Linux服務中

java不用做任何改動就可以部署到linux系統，java編譯成*.class文件只需要虛擬機的支持，你只要在linux環境下裝一個jdk就OK了，然後配置一下環境變量。 然後java的class文件或者打包好的*.jar文件考到linux目錄下就可以用了. 望採納！

jsvc和直接運行java的區別

不能使用tomcat啟動運行，tomcat啟動運行一定是一個web項目。如果想運行JAVA應用程序（非web），可以使用 apache 的一個獨立的工具，jsvc，apache 也推薦使用jsvc啟動tomcat

tomcat jsvc是什麼

用來啟動tomcat，在linux下面使用

在linux上以服務的方式啟動java程序

1.安裝jsvc

在tomcat的bin目錄下有一個jsvc.tar.gz的文件,進入tomcat的bin目錄下

#tar xvfz jsvc.tar.gz

#cd jsvc-src

#sh support/buildconf.sh

#chmod 755 configure

#./configure –with-java=/usr/local/java (改成你的JDK的位置)

#make

2.編寫服務啟動類

package com.sohu.jsvc.test;

public class TestJsvc {

public static void main(String args[]) {

System.out.println(“execute main method!”);

}

public void init() throws Exception {

System.out.println(“execute init method！”);

}

public void init(String[] args) throws Exception{

System.out.println(“execute init(args) method”);

}

public void start() throws Exception {

System.out.println(“execute start method！”);

}

public void stop() throws Exception {

System.out.println(“execute stop method！”);

}

public void destroy() throws Exception{

System.out.println(“execute destroy method!”);

}

}

main方法可以去掉，但是init(String[] args),start(),stop(),destroy()方法不能少，服務在啟動時會先調用init(String[] args)方法

然後調用start()方法，在服務停止是會首先調用stop()方法，然後調用destroy() 方法.

3.把這個類打包成testjsvc.jar 放到/test目錄下

4.編寫啟動服務的腳本 myjsvc

#!/bin/sh

# myjsvc This shell script takes care of starting and stopping

#

# chkconfig: – 60 50

# description: tlstat stat is a stat data daemon.

# processname: myjsvc

# Source function library.

. /etc/rc.d/init.d/functions

RETVAL=0

prog=”MYJSVC”

# jdk的安裝目錄

JAVA_HOME=/usr/java/jdk1.5.0_15

#應用程序的目錄

MYJSVC_HOME=/test

#jsvc所在的目錄

DAEMON_HOME=/usr/local/tomcat5/bin/jsvc-src

#用戶

MYJSVC_USER=root

# for multi instances adapt those lines.

TMP_DIR=/var/tmp

PID_FILE=/var/run/tlstat.pid

#程序運行是所需的jar包，commons-daemon.jar是不能少的

CLASSPATH=/test/testjsvc.jar:/usr/local/tomcat5/bin/commons-daemon.jar:

case “$1” in

start)

#

# Start TlStat Data Serivce

#

$DAEMON_HOME/jsvc -user $MYJSVC_USER -home $JAVA_HOME -Djava.io.tmpdir=$TMP_DIR -wait 10 -pidfile $PID_FILE #控制台的輸出會寫到tlstat.out文件里

-outfile $MYJSVC_HOME/log/myjsvc.out -errfile ‘1’ -cp $CLASSPATH #服務啟動類

com.sohu.jsvc.test.TestJsvc

#

# To get a verbose JVM

#-verbose # To get a debug of jsvc.

#-debug exit $?

;;

stop)

#

# Stop TlStat Data Serivce

#

$DAEMON_HOME/jsvc -stop -pidfile $PID_FILE com.sohu.jsvc.test.TestJsvc

exit $?

;;

*)

echo “Usage myjsvc start/stop”

exit 1;;

esac

5. 把myjsvc文件拷貝到/etc/init.d/目錄下

6. #chmod -c 777 /etc/init.d/myjsvc

7. 添加服務

#chkconfig –add myjsvc

#chkconfig –level 345 myjsvc on

8. 完成，啟動服務

#service myjsvc start

你可以從/test/log/myjsvc.out文件里看到如下信息:

execute init(args) method

execute start method

#service myjsvc stop

你會發現/test/log/myjsvc.out文件里會增加如下信息

execute stop method

execute destroy method

並且在系統重啟時會自動啟動myjsvc服務

好了，一個簡單的 liunx服務就寫好了，你可以在TestJsvc的init(),start(),stop(),destroy()方法里添加你的業務，做你想做的事。

Tomcat篇02-整體架構和I/O模型

本文主要包括tomcat服務器的目錄結構、工作模式、整體架構、I/O模型以及NIO、NIO2、APR三者的對比介紹。

我們先來看一下tomcat8.5和tomcat9中的home目錄中的文件：

可以看到除掉一些說明文件之後，還有7個目錄：

實際上除了主目錄里有lib目錄，在webapps目錄下的web應用中的WEB-INF目錄下也存在一個lib目錄：

兩者的區別在於：

●　Tomcat主目錄下的lib目錄：存放的JAR文件 不僅能被Tomcat訪問，還能被所有在Tomcat中發佈的Java Web應用訪問

●　webapps目錄下的Java Web應用的lib目錄：存放的JAR文件 只能被當前Java Web應用訪問

既然有多個lib目錄，那麼肯定就有使用的優先順序，Tomcat類加載器的目錄加載優先順序如下：

Tomcat的類加載器負責為Tomcat本身以及Java Web應用加載相關的類。假如Tomcat的類加載器要為一個Java Web應用加載一個類，類加載器會按照以下優先順序到各個目錄中去查找該類的.class文件，直到找到為止，如果所有目錄中都不存在該類的.class文件，則會拋出異常：

Tomcat不僅可以單獨運行，還可以與其他的Web服務器集成，作為其他Web服務器的進程內或進程外的servlet容器。集成的意義在於：對於不支持運行Java Servlet的其他Web服務器，可通過集成Tomcat來提供運行Servlet的功能。

Tomcat有三種工作模式：

我們先從tomcat的源碼目錄來分析一下tomcat的整體架構，前面我們配置jsvc運行tomcat的時候，我們知道tomcat中啟動運行的最主要的類是 org.apache.catalina.startup.Bootstrap ，那麼我們在tomcat的源碼中的java目錄下的org目錄的apache目錄可以找到主要的源碼的相對應的類。

圖中的目錄如果畫成架構圖，可以這樣表示：

Tomcat 本質上就是一款Servlet 容器，因此 catalina 才是Tomcat的核心 ，其他模塊都是為 catalina 提供支撐的。

單線程阻塞I/O模型是最簡單的一種服務器I/O模型，單線程即同時只能處理一個客戶端的請求，阻塞即該線程會一直等待，直到處理完成為止。對於多個客戶端訪問，必須要等到前一個客戶端訪問結束才能進行下一個訪問的處理，請求一個一個排隊，只提供一問一答服務。

如上圖所示：這是一個同步阻塞服務器響應客戶端訪問的時間節點圖。

這種模型的特點在於單線程和阻塞I/O。 單線程即服務器端只有一個線程處理客戶端的所有請求，客戶端連接與服務器端的處理線程比是 n:1 ，它無法同時處理多個連接，只能串行處理連接。而阻塞I/O是指服務器在讀寫數據時是阻塞的，讀取客戶端數據時要等待客戶端發送數據並且把操作系統內核複製到用戶進程中，這時才解除阻塞狀態。寫數據回客戶端時要等待用戶進程將數據寫入內核並發送到客戶端後才解除阻塞狀態。 這種阻塞帶來了一個問題，服務器必須要等到客戶端成功接收才能繼續往下處理另外一個客戶端的請求，在此期間線程將無法響應任何客戶端請求。

該模型的特點：它是最簡單的服務器模型，整個運行過程都只有一個線程，只能支持同時處理一個客戶端的請求(如果有多個客戶端訪問，就必須排隊等待)， 服務器系統資源消耗較小，但並發能力低，容錯能力差。

多線程阻塞I/O模型在單線程阻塞I/O模型的基礎上對其進行改進，加入多線程，提高並發能力，使其能夠同時對多個客戶端進行響應，多線程的核心就是利用多線程機製為每個客戶端分配一個線程。

如上圖所示，服務器端開始監聽客戶端的訪問，假如有兩個客戶端同時發送請求過來，服務器端在接收到客戶端請求後分別創建兩個線程對它們進行處理，每條線程負責一個客戶端連接，直到響應完成。 期間兩個線程並發地為各自對應的客戶端處理請求 ，包括讀取客戶端數據、處理客戶端數據、寫數據回客戶端等操作。

這種模型的I/O操作也是阻塞的 ，因為每個線程執行到讀取或寫入操作時都將進入阻塞狀態，直到讀取到客戶端的數據或數據成功寫入客戶端後才解除阻塞狀態。儘管I/O操作阻塞，但這種模式比單線程處理的性能明顯高了，它不用等到第一個請求處理完才處理第二個，而是並發地處理客戶端請求，客戶端連接與服務器端處理線程的比例是 1:1 。

多線程阻塞I/O模型的特點：支持對多個客戶端並發響應，處理能力得到大幅提高，有較大的並發量，但服務器系統資源消耗量較大，而且如果線程數過多，多線程之間會產生較大的線程切換成本，同時擁有較複雜的結構。

在探討單線程非阻塞I/O模型前必須要先了解非阻塞情況下套接字事件的檢測機制，因為對於單線程非阻塞模型最重要的事情是檢測哪些連接有感興趣的事件發生。一般會有如下三種檢測方式。

當多個客戶端向服務器請求時，服務器端會保存一個套接字連接列表中，應用層線程對套接字列表輪詢嘗試讀取或寫入。如果成功則進行處理，如果失敗則下次繼續。這樣不管有多少個套接字連接，它們都可以被一個線程管理，這很好地利用了阻塞的時間，處理能力得到提升。

但這種模型需要在應用程序中遍歷所有的套接字列表，同時需要處理數據的拼接，連接空閑時可能也會佔用較多CPU資源，不適合實際使用。

這種方式將套接字的遍歷工作交給了操作系統內核，把對套接字遍歷的結果組織成一系列的事件列表並返回應用層處理。對於應用層，它們需要處理的對象就是這些事件，這是一種事件驅動的非阻塞方式。

服務器端有多個客戶端連接，應用層向內核請求讀寫事件列表。內核遍歷所有套接字並生成對應的可讀列表readList和可寫列表writeList。readList和writeList則標明了每個套接字是否可讀/可寫。應用層遍歷讀寫事件列表readList和writeList，做相應的讀寫操作。

內核遍歷套接字時已經不用在應用層對所有套接字進行遍歷，將遍歷工作下移到內核層，這種方式有助於提高檢測效率。 然而，它需要將所有連接的可讀事件列表和可寫事件列表傳到應用層，假如套接字連接數量變大，列表從內核複製到應用層也是不小的開銷。 另外，當活躍連接較少時， 內核與應用層之間存在很多無效的數據副本 ，因為它將活躍和不活躍的連接狀態都複製到應用層中。

通過遍歷的方式檢測套接字是否可讀可寫是一種效率比較低的方式，不管是在應用層中遍歷還是在內核中遍歷。所以需要另外一種機制來優化遍歷的方式，那就是 回調函數 。內核中的套接字都對應一個回調函數，當客戶端往套接字發送數據時，內核從網卡接收數據後就會調用回調函數，在回調函數中維護事件列表，應用層獲取此事件列表即可得到所有感興趣的事件。

內核基於回調的事件檢測方式有兩種

第一種是用 可讀列表readList 和 可寫列表writeList 標記讀寫事件， 套接字的數量與 readList 和 writeList 兩個列表的長度一樣 。

上面兩種方式由操作系統內核維護客戶端的所有連接並通過回調函數不斷更新事件列表，而應用層線程只要遍歷這些事件列表即可知道可讀取或可寫入的連接，進而對這些連接進行讀寫操作，極大提高了檢測效率，自然處理能力也更強。

單線程非阻塞I/O模型最重要的一個特點是，在調用讀取或寫入接口後立即返回，而不會進入阻塞狀態。雖然只有一個線程，但是它通過把非阻塞讀寫操作與上面幾種檢測機制配合就可以實現對多個連接的及時處理，而不會因為某個連接的阻塞操作導致其他連接無法處理。在客戶端連接大多數都保持活躍的情況下，這個線程會一直循環處理這些連接，它很好地利用了阻塞的時間，大大提高了這個線程的執行效率。

單線程非阻塞I/O模型的主要優勢體現在對多個連接的管理，一般在同時需要處理多個連接的發場景中會使用非阻塞NIO模式，此模型下只通過一個線程去維護和處理連接，這樣大大提高了機器的效率。一般服務器端才會使用NIO模式，而對於客戶端，出於方便及習慣，可使用阻塞模式的套接字進行通信。

在多核的機器上可以通過多線程繼續提高機器效率。最樸實、最自然的做法就是將客戶端連接按組分配給若干線程，每個線程負責處理對應組內的連接。比如有4個客戶端訪問服務器，服務器將套接字1和套接字2交由線程1管理，而線程2則管理套接字3和套接字4，通過事件檢測及非阻塞讀寫就可以讓每個線程都能高效處理。

多線程非阻塞I/O模式讓服務器端處理能力得到很大提高，它充分利用機器的CPU，適合用於處理高並發的場景，但它也讓程序更複雜，更容易出現問題（死鎖、數據不一致等經典並發問題）。

最經典的多線程非阻塞I/O模型方式是Reactor模式。首先看單線程下的Reactor，Reactor將服務器端的整個處理過程分成若干個事件，例如分為接收事件、讀事件、寫事件、執行事件等。Reactor通過事件檢測機制將這些事件分發給不同處理器去處理。在整個過程中只要有待處理的事件存在，即可以讓Reactor線程不斷往下執行，而不會阻塞在某處，所以處理效率很高。

基於單線程Reactor模型，根據實際使用場景，把它改進成多線程模式。常見的有兩種方式：一種是在耗時的process處理器中引入多線程，如使用線程池；另一種是直接使用多個Reactor實例，每個Reactor實例對應一個線程。

Reactor模式的一種改進方式如下圖所示。其整體結構基本上與單線程的Reactor類似，只是引入了一個線程池。由於對連接的接收、對數據的讀取和對數據的寫入等操作基本上都耗時較少，因此把它們都放到Reactor線程中處理。然而，對於邏輯處理可能比較耗時的工作，可以在process處理器中引入線程池，process處理器自己不執行任務，而是交給線程池，從而在Reactor線程中避免了耗時的操作。將耗時的操作轉移到線程池中後，儘管Reactor只有一個線程，它也能保證Reactor的高效。

Reactor模式的另一種改進方式如下圖所示。其中有多個Reactor實例，每個Reactor實例對應一個線程。因為接收事件是相對於服務器端而言的，所以客戶端的連接接收工作統一由一個accept處理器負責，accept處理器會將接收的客戶端連接均勻分配給所有Reactor實例，每個Reactor實例負責處理分配到該Reactor上的客戶端連接，包括連接的讀數據、寫數據和邏輯處理。這就是多Reactor實例的原理。

Tomcat支持的I/O模型如下表（自8.5/9.0 版本起，Tomcat移除了對BIO的支持），在 8.0 之前 ， Tomcat 默認採用的I/O方式為 BIO ， 之後改為 NIO。 無論 NIO、NIO2 還是 APR， 在性能方面均優於以往的BIO。

Tomcat中的NIO模型是使用的JAVA的NIO類庫，其內部的IO實現是同步的（也就是在用戶態和內核態之間的數據交換上是同步機制），採用基於selector實現的異步事件驅動機制（這裡的異步指的是selector這個實現模型是使用的異步機制）。 而對於Java來說，非阻塞I/O的實現完全是基於操作系統內核的非阻塞I/O，它將操作系統的非阻塞I/O的差異屏蔽並提供統一的API，讓我們不必關心操作系統。JDK會幫我們選擇非阻塞I/O的實現方式。

NIO2和前者相比的最大不同就在於引入了異步通道來實現異步IO操作，因此也叫AIO（Asynchronous I/O）。NIO.2 的異步通道 APIs 提供方便的、平台獨立的執行異步操作的標準方法。這使得應用程序開發人員能夠以更清晰的方式來編寫程序，而不必定義自己的 Java 線程，此外，還可通過使用底層 OS 所支持的異步功能來提高性能。如同其他 Java API 一樣，API 可利用的 OS 自有異步功能的數量取決於其對該平台的支持程度。

異步通道提供支持連接、讀取、以及寫入之類非鎖定操作的連接，並提供對已啟動操作的控制機制。Java 7 中用於 Java Platform（NIO.2）的 More New I/O APIs，通過在 java.nio.channels 包中增加四個異步通道類，從而增強了 Java 1.4 中的 New I/O APIs（NIO），這些類在風格上與 NIO 通道 API 很相似。他們共享相同的方法與參數結構體，並且大多數對於 NIO 通道類可用的參數，對於新的異步版本仍然可用。主要區別在於新通道可使一些操作異步執行。

異步通道 API 提供兩種對已啟動異步操作的監測與控制機制。第一種是通過返回一個 java.util.concurrent.Future 對象來實現，它將會建模一個掛起操作，並可用於查詢其狀態以及獲取結果。第二種是通過傳遞給操作一個新類的對象， java.nio.channels.CompletionHandler ，來完成，它會定義在操作完畢後所執行的處理程序方法。每個異步通道類為每個操作定義 API 副本，這樣可採用任一機制。

Apache可移植運行時（Apache Portable Runtime，APR） 是Apache HTTP服務器的支持庫，最初，APR是作為Apache HTTP服務器的一部分而存在的，後來成為一個單獨的項目。其他的應用程序可以使用APR來實現平台無關性（跨平台）。APR提供了一組映射到下層操作系統的API，如果操作系統不支持某個特定的功能，APR將提供一個模擬的實現。這樣程序員使用APR編寫真正可在不同平台上移植的程序。

順利安裝完成後會顯示apr的lib庫路徑，一般都是 /usr/local/apr/lib

安裝完成之後我們還需要修改環境變量和配置參數

這裡我們使用的是systemd調用jsvc來啟動tomcat，所以我們直接在systemd對應的tomcat的unit文件中的 ExecStart 中添加一個路徑參數 -Djava.library.path=/usr/local/apr/lib 指向apr庫的路徑：

然後我們在tomcat的home目錄下的conf子目錄中對server.xml文件進行修改

把8080端口對應的配置修改成apr：（其他端口配置也類似）

重啟tomcat服務我們從tomcat的日誌中就可以看到協議已經從默認的NIO變成了apr。

NIO性能是最差的這是毋庸置疑的，如果是考慮到高並發的情況，顯然異步非阻塞I/O模式的NIO2和APR庫在性能上更有優勢，實際上NIO2的性能表現也和APR不相上下，但是NIO2要求Tomcat的版本要在8.0以上，而APR只需要5.5以上即可，但是APR需要額外配置庫環境，相對於內置集成的NIO2來說APR這個操作比較麻煩，兩者各有優劣。具體使用哪個還是需要結合實際業務需求和環境進行測試才能決定。

linux tomcat 日誌 catalina.out沒有，日誌裏面沒一個文件。

方法有兩種 第一種最簡單 ：在你的tomcat的bin目錄裏面新建一個setenv.sh文件 加入下面兩行，重啟tomcat 就ok。

JAVA_HOME=/usr/java/jdk1.6.0_13/ （根據你的Java安裝目錄修改）

JRE_HOME=/usr/java/jdk1.6.0_13/jre

在不行把下面這種方式試試；

vi /etc/profile //更改環境變量，此次我們更改的是所有用戶的環境變量，打開文件後在最後加入下面三行變量

export JAVA_HOME=/usr/java/jdk1.6.0_13

export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib

export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH:$HOMR/bin

做新的連接，進入/usr/bin目錄下

ln -s -f /usr/java/jdk1.6.0_13/jre/bin/java

ln -s -f /usr/java/jdk1.6.0_13/bin/javac

source /etc/profile //運行環境變量

java –version //查看java版本，顯示版本是1.6.0_13證明安裝成功！

還不行的話，hi交流！

有Hadoop使用kerberos認證經驗的大神沒有

一、部署無kerberos認證的Hadoop環境

參考另一篇筆記：hadoop集群部署

或者按照Cloudera的官方文檔：CDH3 Installation Guide.

二、環境說明

1、主機名

之前部署hadoop集群時，沒有使用節點的hostname，而是在hosts文件里添加了ip要域名的解析，部署後的hadoop沒有問題，但是在為集群添加kerberos認證時因為這一點，遇到很多的問題。所以，建議還是使用節點的hostname來做解析。

集群中包含一個NameNode/JobTracker，兩個DataNode/TaskTracker。

hosts文件

172.18.6.152 nn.hadoop.local

172.18.6.143 dn143.hadoop.local

172.18.6.145 dn145.hadoop.local

注意：hosts文件中不要包含127.0.0.1的解析。

2、hadoop安裝部署相關

hadoop 和kerberos的部署需要hadoop-sbin和hadoop-native。

如果使用的是rpm部署的hadoop，需要安裝上面的兩個rpm包。

我的集群使用的是tar包部署的，所以默認是包含這兩部分文件的，可以檢查一下：

hadoop-sbin對應的文件是：

/usr/local/hadoop/sbin/Linux-amd64-64

文件夾中包含兩個文件：jsvc、task-controller

hadoop-native對應的目錄是：

/usr/local/hadoop/lib/native

3、AES-256加密

我的系統使用的是centos6.2和centos5.7，對於使用centos5.6及以上的系統，默認使用AES-256來加密的。這就需要集群中的所有節點和hadoop user machine上安裝 Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File

打開上面的鏈接，在頁面的下方，下載jdk對應的文件，jdk1.6.0_22下載下面的文件：

註：如果後面出現login failed的錯誤，應先檢查是否是從官方網站下載的JCE。

下載的文件是一個zip包，解開後，將裏面的兩個文件放到下面的目錄中：

/usr/java/jdk1.6.0_22/jre/lib/security

註：也可以不使用AED-256加密，方法見官方文檔對應的部分。

三、部署KDC

1、安裝kdc server

只需要在kdc中安裝

yum install krb5-server.x86_64 krb5-devel.x86_64

2、配置文件

kdc服務器涉及到三個配置文件：

/etc/krb5.conf、

/var/kerberos/krb5kdc/kdc.conf、

/var/kerberos/krb5kdc/kadm5.acl

hadoop集群中其他服務器涉及到的kerberos配置文件：/etc/krb5.conf。

將kdc中的/etc/krb5.conf拷貝到集群中其他服務器即可。

集群如果開啟selinux了，拷貝後可能需要執行restorecon -R -v /etc/krb5.conf

/etc/krb5.conf

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = for_hadoop

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 2d

forwardable = true

renewable = true

[realms]

for_hadoop = {

kdc = 172.18.6.152:88

admin_server = 172.18.6.152:749

}

[domain_realm]

[kdc]

profile=/var/kerberos/krb5kdc/kdc.conf

/var/kerberos/krb5kdc/kdc.conf

[kdcdefaults]

kdc_ports = 88

kdc_tcp_ports = 88

[realms]

for_hadoop = {

master_key_type = aes256-cts

max_life = 25h

max_renewable_life = 4w

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md

5:normal des-cbc-crc:normal

}

/var/kerberos/krb5kdc/kadm5.acl

*/admin@for_hadoop *

3、創建數據庫

#kdb5_util create -r for_hadoop -s

該命令會在/var/kerberos/krb5kdc/目錄下創建principal數據庫。

4、關於kerberos的管理

可以使用kadmin.local或kadmin,至於使用哪個，取決於賬戶和訪問權限：

kadmin.local（on the KDC machine）or kadmin （from any machine）

如果有訪問kdc服務器的root權限，但是沒有kerberos admin賬戶，使用kadmin.local

如果沒有訪問kdc服務器的root權限，但是用kerberos admin賬戶，使用kadmin

5、創建遠程管理的管理員

#kadmin.local

addprinc root/admin@for_hadoop

密碼不能為空，且需妥善保存。

6、創建測試用戶

#kadmin.local

addprinc test

7、常用kerberos管理命令

#kadmin.local

列出所有用戶 listprincs

查看某個用戶屬性，如 getprinc hdfs/nn.hadoop.local@for_hadoop

注意，是getprinc，沒有’s’

添加用戶 addprinc

更多，查看幫助

8、添加kerberos自啟動及重啟服務

chkconfig –level 35 krb5kdc on

chkconfig –level 35 kadmin on

service krb5kdc restart

service kadmin restart

9、測試

使用之前創建的test用戶

# kinit test

Password for test@for_hadoop:

#