A Day In The Boy's Life -37ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

最近は少し規模が大きなシステムの構成となると、大容量ストレージを使うケースが多かったりします。

ストレージがNFSを喋れる場合は、NFS経由でマウントするのが楽だったりもしますが、iSCSI経由でも少しの設定で同様にネットワーク上にあるディスクボリュームをローカルディスクのように扱うことができます(iSCSIは排他ロックができないのでNFSとは用途が違うといえば違いますが)。

ということで、リモートにあるディスクiSCSIを使い、Ext4のファイルシステムのディスクボリュームをマウントする方法のまとめです。

環境は、RedHat6.2を利用しています。

なお、ストレージ側(マウントされる側)の設定は省略しています。

 

 

iSCSIでターゲットとなるディスクボリュームをマウントする

 

まずは、iSCSIを利用するためのパッケージが用意されているか確認する必要があります。

 

# rpm -qa | grep iscsi
iscsi-initiator-utils-6.2.0.872-34.el6.x86_64

 

上記のように、iSCSIイニシエータのパッケージが入っているか確認します。

存在しない場合は、yum経由とかでインストールしておきましょう。

パッケージが入っているとiscsiadmコマンドが利用できますので、それでホスト(ターゲット)となるストレージを探します。

 

# iscsiadm -m discovery -t sendtargets -p 192.168.0.1

 

指定するIPはターゲットなるストレージ側のIPアドレスです。

コマンドと実行後、ストレージ側で公開されているディスクボリュームの情報(IQN)が下記ディレクトリに展開されます。

 

# ls -la /var/lib/iscsi/nodes
合計 20
drwxr-xr-x. 5 root root 4096  7月 30 16:36 2013 .
drwxr-xr-x. 8 root root 4096  6月  7 15:08 2013 ..
drw-------  3 root root 4096  7月 30 16:35 2013 iqn.2001-05.com.foo:0-1cb196-cc3294a2d-f1f000167e151b82-bar1
drw-------  3 root root 4096  7月 30 16:35 2013 iqn.2001-05.com.foo:0-1cb196-f6a294a2d-c02000167ed51b82-bar2

 

ただし、不要(マウントしない)なボリュームもあるでしょうから、それらは事前に削除しておきます。

削除は、上記ディレクトリを直接削除しても良いですし、下記のコマンドでIQNを指定して削除することもできます。

 

# iscsiadm -m node -o delete -T iqn.IQN情報

 

続いて、iSCSI経由でターゲットにログインします。

 

iscsiadm -m node --login

 

ログインできたかどうかは、セッション情報を確認してみるとわかります。

 

# iscsiadm -m session
tcp: [1] 192.168.0.1:3260,1 iqn.2001-05.com.foo:0-1cb196-cc3294a2d-f1f000167e151b82-bar1

 

ターゲットへのログインが成功したら、ローカルのデバイスとして認識されているかを確認します。

 

# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  8月  9 12:56 2013 ip-192.168.0.1:3260-iscsi-iqn.2001-05.com.foo:0-1cb196-cc3294a2d-f1f000167e151b82-bar1-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root  9  8月  9 12:56 2013 pci-0000:02:00.0-scsi-0:2:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10  8月  9 12:56 2013 pci-0000:02:00.0-scsi-0:2:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10  8月  9 12:56 2013 pci-0000:02:00.0-scsi-0:2:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10  8月  9 12:56 2013 pci-0000:02:00.0-scsi-0:2:0:0-part3 -> ../../sda3

 

上記のように、ターゲット内で見つけたbar1のボリュームがローカルの/dev/sdbにマウントされていることがわかります。

ただし、このデバイス名はOSを再起動したりすると変わる可能性があるため、デバイス名を固定するための設定をしておきます。

固定する方法は、特定のSCSI IDであったら固定のデバイス名にするというものです。

そのため、まずはSCSI IDを調べます。

 

# scsi_id -g /dev/sdb
36019cbd1a29432cc821b157e1600f0f1

 

上記のSCSI IDのデバイスを固定するためのルールを設定ファイルに記述します。

ファイルが存在しない場合は、新規作成します。

 

KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/scsi_id -g /dev/%k", RESULT=="36019cbd1a29432cc821b157e1600f0f1", NAME="bar1", OWNER:="fuga", GROUP:="hoge", MODE:="0660" 

 

「RESULT==」とかかれたところに、先ほどのSCSI IDを設定しておきます。

NAMEがデバイス名となり、OWNERやGROUPはボリュームをマウントしたときの所有者とグループ名になります。

 

※ うまくいかないときは下記のエントリも参照してみてください。

 

udevを使ってデバイス名の固定する

 

 

ターゲットボリュームのファイルシステムをExt4へフォーマットする

 

ボリュームがサーバーから認識できるようになったら、その領域のファイルシステムをExt4へフォーマットします。

 

# fdisk /dev/sdb
デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
含んでいません
新たに DOS ディスクラベルをディスク識別子 0xb1eeb347 で作成します。
あなたが書き込みを決定するまで、変更はメモリ内だけに残します。
その後はもちろん以前の内容は修復不可能になります。
警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
正常になります

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。 and change display units to
         sectors (command 'u').

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 1
最初 シリンダ (1-65272, 初期値 1):
初期値 1 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (1-65272, 初期値 65272):
初期値 65272 を使います

コマンド (m でヘルプ): p

ディスク /dev/sdb: 536.9 GB, 536881397760 バイト
ヘッド 255, セクタ 63, シリンダ 65272
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0xb1eeb347

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdb1               1       65272   524297308+  83  Linux

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

 

やっていることは、fdiskコマンドを使って基本パーティションを作成するというものです。

パーティションの作成が終ったら、その領域をExt4でフォーマットしてあげます。

 

# mkfs.ext4 /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
32776192 inodes, 131074327 blocks
6553716 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
4001 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

 

フォーマット完了後は、サーバーからマウントして見ましょう。

 

# mount -t ext4 /dev/sdb1 /export

 df -k
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda3             15000964   3383136  10855820  24% /
tmpfs                   961900         0    961900   0% /dev/shm
/dev/sda1               495844     36945    433299   8% /boot
/dev/sdb1            516068876    202520 489651492   1% /export

 

これで、/exportとしてサーバーからマウントできていますので、後はread/writeのテストをしてみれば良いかと思います。

問題なければ、永続的にサーバーからマウントされるようにfstabに情報を追加しておきます。

 

/dev/sdb1             /export              ext4    _netdev        1 1

 

これで、iSCSI経由でリモートにあるディスクボリュームをローカルにあるかのように使うことができます。

 

 

 

 

 

 

 

 

人それぞれ個性があるが故に、様々な考えを持ってたりスタイルがあったり生き方があるわけですが、多くの人に受入れられる無難さって言うのはそれと反するイメージが強くあまり好まれるように見えません。

ただ、多くの人に受入れられるっていう面ではこの無難さって言うのは結構大事なんだなって思うときがあります。



無難というのは自然に受入れられること


例えばファッションを取ってみても、おしゃれというのは一見して奇抜なように見え、到底自分には真似できないように思えます。

その格好はその人の個性とあいまって価値観を増して輝かせたりもしますが、多くの人が受入れられないのは事実です。


また、自分がおしゃれと思っていても周りの女の子とかに聞いてみると「自分の好みではない」「実際に近くにいたら引くわぁ~」とか本音を言われたりしてギャップを感じることがしばしばですが、無難なファッションというものも存在します。

「格好良くもないんだけど、悪くないよね」「目立たないけどセンスはいい」というような感じで要は見た人が嫌悪感を示さない格好です。


こういう風に、できるだけ多くの人が自然に受入れられる意見であったり行動であったりスタイルを持つというのはすごく難しいことです。

無難にこなすというのは、極端な意見であったり考えであったりスタイルであったりがないので、多くの人にとっては目立たない存在にはなるのですが、これはある意味面白みがないことにもなります。
嫌悪感を示さないわけであって、ひどく納得して受入れられたというのではないわけですから、下手したらどっちでもよいということにも扱われます。


そして、ひどく無難な意見というのはその人の意見ではないように受取られ返って嫌悪感を抱く対象となってしまいます。

「君の意見はないのか」って言うところなんですが、変に白黒つけようとしたがる雰囲気があまり自分は好きではなかったりするので、アンケートにはある「よくわからない」って項目のように受け流すことも必要なんじゃないかなと感じたりもするんですが、日本人はこういう曖昧なところが好きな人も多いので、日本人らしい考え方なのかもしれません。


人それぞれ考え方があるので、100%受入れられる答えなどありません。
無難というのはせいぜい半分かもう少し上の辺りまでの割合で受入れられたら良い方だと思います。

残りもさらに細分化されるので、ある一方的な意見を言ったところでその他の人たちがついてくるわけでもなく、せいぜい数%かもっと極端に少ない割合の人たちが同意するレベルの意見であって、「君の意見はないのか」の解としてそこに響くことを言ってもそれって意味があることなのか、って思ってしまいます。

まぁ、人それぞれ意見があるんだからそれをぶつける事が大切っていう無難な意見は言えるわけですが。



無難に染まるために自分を押し殺せるか


少し開発者よりの話にはなりますが、何故無難さというのが大事なのかって、それを使う人や作る人のできるだけ多くを納得させないといけないからです。

UIの話にしたって「俺はこのUIがいい」「俺はこの色が好みだ」って言ったところで、それが万人受けするわけではありません。

今では、過去の統計から導いたベストプラクティスや人間工学に基づいた情報があり、若い人に受ける流行のインターフェースであったり、年配の人が好む色であったり、そういうのが一般化してきたりしています。

ひどく奇抜なUIを使うのがよいのか、無難に使えるUIがよいのかどちらが多くの人に受入れられるためには良いのかと考えたら自然に後者になるでしょう。

要はそれも多くの人が自然と受入れられるノウハウの集大成であって、変にとんがったり斬新なものではなかったりするわけです。


こうなってくると何が無難なのかと考えるのは、自分のスタイルが無難なのかどうなのかってことにもなりかなり混乱してきます。
多くの人は、「自分は普通だ」って思っているんですが、大体は(自分も)当てはまってないからです
多くの人に受入れられるはずの考えを持っている、服装もしている、食べ物の好みだって普通だし・・・って思っていると意外と当てはまらないことは多かったりします。

一分野で標準だとしても他の分野すべてが一般的な考えを持っているわけではないわけなんですが、物を作るって観点から見ると多種多様な分野を横断的に妥当を当てはめていかなくてはならず、それは一部では自分とのギャップを押し殺しながら進まなくてはならなくなります。


まぁ、先進的なものを作ってそれがスタンダードになるようなものを作るべきだという意見もあるとは思いますが、いきなりそんな先進的なものを投入してもみんなに受入れられるわけではないので、多くの人にとっての普通を先進的なものにするためのギャップを埋める道筋を、その多くの人がついてくるように導く戦略は必要になってくるでしょう。

そこでもまた多くの人に受入れられるための考えというものが求められます。



まとめ


ということで、無難というのは意見がないこととは違って、多くの人に受入れられるための特異な考え方かもしれません。

自分の色を出さずに他の人の色に合わせられるというのは、自分を自由に変化させられる能力が必要になってきます。
八方美人で誰にでも良いように顔色を変えていくということではありません。


母数に対しての中央値をわかってないといけませんし、それと自分がどれほどギャップがあるのかということを分析する必要もありますし、それを埋めるためにある意味自分の好みを捨てる必要も出てきます。

そういったことを経て、案外無難な意見を言うというのは難しいことなんだなと感じています。





Apache Solrをデフォルトのままで利用しようとすると、管理サイトへのアクセスや検索や情報の更新もどこからでもできたりします。

これは、セキュリティ的にまずいので、Solrへのアクセスを制御する方法をまとめてみます。

なお、環境はRedHat5.9にApache Solr4.2を利用した環境です。

Solrは付属のJettyで動かしているので、その他の環境で動かしている場合は設定が異なるかと思います。



Solr(Jetty)がListenするIPアドレスを限定したアクセス制御


管理サイトをつぶしてしまってかまわないのであれば、JettyがListenするIPアドレスを下記のようにローカルホストからのみに変更するのが手っ取り早い方法かもしれません。


<New class="org.eclipse.jetty.server.bio.SocketConnector">
  <Set name="host"><SystemProperty name="jetty.host" /></Set>
  <Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>


jetty.xmlの54行目あたりにある上記の箇所を


<Set name="host"><SystemProperty name="jetty.host" default="127.0.0.1" /></Set>
または
<Set name="host">127.0.0.1</Set>


※ 編集後は要Solr再起動。


のように設定することで、localhostからしかアクセスできなくなります。

要はListenするサーバーのIPアドレスが、127.0.0.1になるのでサーバーローカルからしかアクセスできなくなります。

もちろんそのサーバーにGUIでアクセスできる環境があるのであれば、そこからは管理サイトへアクセス可能です。

そして、検索結果の取得やSolr内の情報の更新もlocalhostからの接続に限定できます。


もしサーバーに複数のN/Wの足が出ていて、サービス用(ユーザーがアクセスする)とマネジメント用(管理者がアクセスする)のN/Wに接続されているようなサーバーであればマネジメント用のIPアドレスをListenさせることで、Solrへのアクセスを限定できたりします。


こういった制限を加えた状態で、Solrのサンプルでついているpost.shを利用してUPDATEしようとしてみると、

$ ./post.sh foo.xml
Posting file foo.xml to http://192.168.0.1:8983/solr/collection1/update
curl: (7) couldn't connect to host


というように、接続できないことがわかります。



Solr(Jetty)へ接続するIPアドレスを限定したアクセス制御


もう1つのやり方は、接続元のIPアドレスを限定するやり方です。

このIPアドレスを持つクライアントからしか接続させない、というやり方です。


まず、先ほど書いたListenするIPアドレスはデフォルトの状態(全てで受付ける)に戻しておきます。

次に、jetty.xmlの108行目あたりを以下のように編集します。


<Array type="org.eclipse.jetty.server.Handler">
  <Item>
<!--
             <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection"/>
-->
    <New class="org.eclipse.jetty.server.handler.IPAccessHandler">
      <Call name="addWhite">
        <Arg>192.168.0.1</Arg>
      </Call>
      <Set name="handler">
        <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection"/>
      </Set>
    </New>
  </Item>

※ 編集後は要Solr再起動。


コメントアウトしている箇所は、元々設定ファイルに書かれていた内容ですので、削除してもかまいません。

「addWhite」属性のArgタグに書かれているのが許可したい接続もとのIPアドレスです。

N/Wで制限したい場合は、


<Call name="addWhite">
  <Arg>192.</Arg>
</Call>


という風に書いておきます。
これで、許可していないIPから接続しようとすると


$ ./post.sh foo.xml
Posting file foo.xml to http://localhost:8983/solr/collection1/update

<html>
<head>
<meta

 http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 403 Forbidden</title>
</head>
<body>
<h2>HTTP ERROR: 403</h2>
<p>Problem accessing /solr/collection1/update. Reason:
<pre>    Forbidden</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>
</body>
</html>


というようにHTTPステータスコード403が返ってきて拒否されます。



Solrの管理サイトやUPDATE実行時にBasic認証をかける


N/W制限に加えて管理サイトやSolrの情報をUPDATEする箇所にパスワードをかけられたらよりセキュリティは高まるでしょう。

ただし、この方法はBasic認証を使うやり方なので、それほど堅牢ではありませんが。

まず、jetty.xmlの設定ファイル内の適当な箇所(一番最後とか)に下記の設定を埋め込みます。


<Call name="addBean">
  <Arg>
    <New class="org.eclipse.jetty.security.HashLoginService">
      <Set name="name">Admin Realm</Set>
      <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
      <Set name="refreshInterval">0</Set>
    </New>
  </Arg>
</Call>


続いて、同フォルダ内にあるwebdefault.xmlの適当な箇所に下記の情報を追加します。


<login-config>
  <realm-name>AdminAuth</realm-name>
</login-config>
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Admin</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin-role</role-name>
  </auth-constraint>
</security-constraint>


最後に、jetty.xmlで指定したユーザー用の設定ファイル(realm.properties)を同じくetcディレクトリ直下に作成します。


admin:admin, admin-role

書式としては、「ユーザー名:パスワード, ロール名」です。

これで、Apache Solrを再起動し管理サイトにアクセスしてみるとBasic認証がかかっているはずです。


A Day In The Boy&#39;s Life-Solr-Basic認証


ちなみに、この状態だと検索やUPDATEもBasic認証がかけられるため、今まで使っていたプログラムも変更する必要があります。

そのため、付属のpost.shでUPDATEするシェルスクリプトも下記のように変更しておきます。


FILES=$*
URL=http://localhost:8983/solr/collection1/update

for f in $FILES; do
  echo Posting file $f to $URL
  curl $URL -u admin:admin --data-binary @$f -H 'Content-type:application/xml'
  echo
done

curl -u admin:admin "$URL?softCommit=true"
echo


変更箇所は、curlの実行オプションに「-u」をつけ、Basic認証用のユーザー/パスワードを指定しているだけです。

データの送信とコミットは分けて実行しているので2箇所とも変更する必要があります。
(1箇所しか変更しないでBasic認証が通らずにはまりました・・・)


Basic認証に失敗すると下記のようにHTTPステータスコード401が返ってきます。


$ ./post.sh foo.xml
Posting file foo.xml to http://localhost:8983/solr/collection1/update
<html>
<head>
<meta
 http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 401 Unauthorized</title>
</head>
<body><h2>HTTP ERROR 401</h2>
<p>Problem accessing /solr/collection1/update. Reason:
<pre>    Unauthorized</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
</body>
</html>


もし、管理サイトとUPDATEのBasic認証用のユーザーを分けたい、もしくはSolrからの検索はBasic認証なしに通したい、という場合は下記のように項目を分けて設定することもできます。


<login-config>
  <realm-name>AdminAuth</realm-name>
</login-config>
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Admin</web-resource-name>
    <url-pattern>/admin/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin-role</role-name>
  </auth-constraint>
</security-constraint>

<security-constraint>
  <web-resource-collection>
    <web-resource-name>FileUpload</web-resource-name>
    <url-pattern>/collection1/update/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>guest-role</role-name>
  </auth-constraint>
</security-constraint>


前半分は、管理サイト用のURL(/admin/*)に、後半部分がUPDATEをする際のURL(/collection1/update/*)に対してBasic認証をかけています。


パスワードファイルも、下記のようにユーザーを追加し、ロールを分けておきます。


guest:guest, guest-role
admin:admin, admin-role

これで、guestユーザーはUPDATE時にだけ使え、adminユーザーは管理サイトへのアクセスできるユーザーとして登録できます。



Solr(Jetty)の起動・停止時のポート番号を変更する


Apache Solrはデフォルトでポート8983を使うので、何も制限をかけてない状態でそのまま利用しておくと管理サイトや情報検索・更新が外部から可能になってしまいます。

ということで、他で利用していないオリジナルのポート番号に変更することで、変にアクセスされるリスクを幾分か低下させることができます。


まず、起動時のポート番号の変更ですが、jetty.xmlを編集します。
今回は、8080番ポートを利用するように変更してみます。


<Call name="addConnector">
  <Arg>
      <New class="org.eclipse.jetty.server.bio.SocketConnector">
        <Set name="host"><SystemProperty name="jetty.host" /></Set>
        <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>
        <Set name="maxIdleTime">50000</Set>
        <Set name="lowResourceMaxIdleTime">1500</Set>
        <Set name="statsOn">false</Set>
      </New>
  </Arg>
</Call>

port属性のdefault値を8080変更します。
続いて、solr.xmlを編集します。


<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true">
  <cores defaultCoreName="collection1" adminPath="/admin/cores" zkClientTimeout="${zkClientTimeout:15000}" hostPort="8080" hostContext="solr">
    <core schema="schema.xml" loadOnStartup="true" instanceDir="collection1/" transient="false" name="collection1" config="solrconfig.xml" dataDir="data"/>
</solr>


編集箇所は、hostPort値の箇所を8080に変更しています。
これで、起動時のSolrの利用するポートを変更できます。


続いて、停止時のポート番号ですが、「Apache Solrを利用して本格的な検索エンジンを導入する 」にて紹介した起動スクリプトを見るとわかりますが、Solrを起動する際に「DSTOP.PORT」というポート番号(8079)を指定しています。

これは、Jettyの仕様で停止コマンドを受付けるポートを起動時に指定できるというもので、「DSTOP.KEY」で指定したキーの値がパスワード代わりとなり、セットで揃っていればJettyの停止ができるというものです。


ですので、停止時のポート番号は起動スクリプトを編集するなどして、起動時のオプションを変更することで変える事ができます。


KEY=stopkey
CORE=solr
cd $JETTY_HOME_DIR
start() {
  $JAVA -Dsolr.solr.home=$CORE -DSTOP.PORT=6060 -DSTOP.KEY=$KEY -jar start.jar >> $LOG_FILE 2>&1 &
  echo "Solr started!"
}
 
stop() {
  $JAVA -DSTOP.PORT=6060 -DSTOP.KEY=$KEY -jar start.jar --stop
  echo "Solr stopped!"
}


上記の場合は、停止時のポート番号を6060に指定してSolrを起動しています。
ポート番号は適当に空いているものを利用してください。



ここで紹介したことも含め、Solrのマニュアル の方も確認してみてください。