とりあえずリソース作ってみる

pacemaker が起動したので、今度は リソース を作ってみる。

pacemaker ってのは、その上で動かす(クラスタ制御下に置く)サービス(例えばデータベースサービス)とかを、リソースと呼ばれる単位の集まりで制御している。
意味がわからんね。

HAクラスタを実現するためには、大きく3つの物を制御する必要がある。

1. サービス用IPアドレス
2. サービス用ディスク
3. サービスプロセス

例えばデータベースをクラスタ化する場合、

• クライアントからアクセスを受け付けるIPアドレス
  サービスを提供する方のノード(サーバ)に、このIPアドレスを付与する。
• データやプログラムが入っているディスク
  サービスを提供する方のノード(サーバ)で、このディスクをマウントする。
• データベースプロセスそのもの
  上の2つが整ったら、データベースを起動する

という感じだ。
(これら3要素のうち、幾つかを必要としないサービスも存在する)

で、pacemaker では、これらの要素1つ1つを「リソース」として登録し、リソースの組み合わせでサービスを提供する形になっている。

あくまでとりあえず、1つリソースを登録してみる。
IPアドレスが簡単かな？

登録は crm コマンドを使用する。
また、リソースは resource agent (ra)というキットに用意されているものを使用するのがラクだ。(自分で作ることも出来るけど、それはまた後日…)
というわけで、ra の確認だが…。
ra はクラスごとに分けられている。
まずは、クラスの一覧を確認してみよう。
(gemini) $ crm ra classes
lsb
ocf / .isolation heartbeat lvm2 pacemaker redhat
service
stonith
systemd
5個出てきた。
それぞれ、
lsb : linux standard base (/etc/init.d のスクリプトだ)
ocf : Open Cluster Framework 準拠のサービス
service : service コマンドで起動停止する対象のサービス
stonith : stonith 専用の処理
systemd : systemd のルールに則ったサービス
という意味だ。うん。さっぱり分からんね。

殆どは ocf クラスに定義されていると思っていい。
ただ、今まで /etc/init.d や systemd によって起動停止していたサービスを pacemaker によってクラスタ化する、というのであれば、lsb や systemd 等のクラスに定義されているはずだ。

IPアドレスは ocf に定義されているが、一応リストを見てみよう。
(gemini) $ crm ra list lsb
(gemini) $ crm ra list ocf
(gemini) $ crm ra list service
(gemini) $ crm ra list stonith
(gemini) $ crm ra list systemd

たくさん出てきたと思うが、ocf の中に IPaddr、IPaddr2、IPsrcaddr、IPv6addr というソレっぽいのが見つかったと思う。
答えから言ってしまうと IPaddr2 が今回使用する ra だが、これらの詳細を確認するコマンドも実行しておこう。
(gemini) $ crm ra info ocf:IPaddr
(gemini) $ crm ra info ocf:IPaddr2
(gemini) $ crm ra info ocf:IPsrcaddr
(gemini) $ crm ra info ocf:IPv6addr

ざっと見ても分かる通り、IPaddr2 が Linux 専用に用意された ra だ。
専用というぐらいだから、これを使うのがいいだろう。

パラメータは…
ip
nic
cidr_netmask
broadcast
iflabel
lvs_support
lvs_ipv6_addrlabel
lvs_ipv6_addrlabel_value
mac
clusterip_hash
unique_clone_address
arp_interval
arp_count
arp_bg
arp_mac
arp_sender
flush_routes
だ。(結構あるな…)
さらに、オペレーションデフォルト値として、
start timeout=20s
stop timeout=20s
status timeout=20s intervals=10s
monitor timeout=20s intervals=10s
とある。
まぁ、必須なのは最初の ip だけなので、これだけ指定して作ってみよう。

(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
おっと！
ERROR: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources:     Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources:     NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit (y/n)?
というエラーが出た。
とりあえず、最後の質問には n と答えておく。

どうやら、stonith の設定を施すか、stonith 自体を無効化しておく必要があるようだ。

stonith ってのは、どうやら対向ノードが完全クラッシュではなく、中途半端に止まってしまった時に、強制的に再起動等を実施する仕組みのようだ。
今回、gemini / cancer でクラスタにしないサービスも稼働させるツモリなので、再起動はしないようにしておきたい。
なので、stonith を無効にする。
無効にするには、stonith として null を使用するか、stonith 自体を無効化するようだ。
null を使用するのはあくまでテスト目的のようだが、今回は敢えて null を使用してみたい。

まずは stonith の一覧確認。
(gemini) $ crm ra list stonith
たくさん出てくるが、null というのがあるか確認しておく。

stonith:null の詳細確認。
(gemini) $ crm ra info stonith:null

実際に設定してみる。
(ココでは、stonith2gemini というのが gemini 障害時に gemini を強制再起動させるリソース、stonith2cancer というのを cancer 障害時に cancer を強制再起動させるリソースとして想定している。null エージェントなので、実際には何も起きないはずだが。)
(gemini) $ sudo crm configure primitive stonith2gemini \
stonith:null \
params \
hostlist="gemini"
(gemini) $ sudo crm configure primitive stonith2cancer \
stonith:null \
params \
hostlist="cancer"
を？すんなり通った。

出来たのだろうか…？
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon
動いているようだ。

ただこのままでは、stonith2gemini が gemini で、stonith2cancer が cancer で稼働してしまうかもしれない。
そのため、リソースが稼働するサーバ(ノード)を固定させる必要がある。

どうやら、 location という定義で指定できるようだ。
(gemini) $ sudo crm configure help location
ヘルプを見てみると、どうやら以下のような記述でリソース稼働を固定させることが出来るようだ。
location ＜識別子＞ ＜リソース名＞ \
rule 100: #uname eq ＜リソースを動かしたいノード名＞ \
rule -INFINITY: #uname eq ＜リソースを動かしたくないノード名＞
＃-INFINITY は -inf と書くことも出来るみたいだ。

これを実際に適用するコマンドは以下の通り。
(gemini) $ sudo crm configure \
location stonith2gemini_loc stonith2gemini \
rule 100: \#uname eq cancer \
rule -inf: \#uname eq gemini
(gemini) $ sudo crm configure \
location stonith2cancer_loc stonith2cancer \
rule 100: \#uname eq gemini \
rule -inf: \#uname eq cancer
＃コマンドラインから実行する場合、 #uname でシェルのコメントになってしまう。
＃そのため、 \ でコメントを無効化しよう。

出来上がったか確認。
(gemini) $ sudo crm_mon -A
(gemini) $ sudo crm configure show

設定は出来たっぽい。

さて、とりあえずこの2つ、起動停止してみたい。(単なるリソースだから、起動停止できるはず…)
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm resource stop stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
止まったっぽい。
今度は起動。
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm resource start stonith2cancer
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
ちゃんと起動したっぽい。

起動停止させると、それぞれの syslog にも記録される。
これ、強制的にノードを指定して起動させるコマンドは無いのだろうか？
(対向ノードでは起動しない設定(-inf)なので、ノード指定の起動はエラーになるはず…)

う～ん。調べてみても、リソースを起動する時に、ノードを指定する方法が見当たらない。起動しているリソースを、他のノードに移動させる、というコマンドなら用意されているようだ。
それが resource migrate コマンドのようだ。(crm help resource migrate で簡単なオプションが表示される)
試してみよう。
(gemini) $ sudo crm status --verbose
stonith2gemini が cancer 上で動いており、stonith2cancer が gemni 上で動いているのが分かる。

では、stonith2gemini を gemini 上に移動させてみよう。(移動出来ないのが正解のはずだ。)
(gemini) $ sudo crm resource migrate stonith2gemini gemini
…何もエラーは起きない。

どうなっただろうか。
(gemini) $ sudo crm status --verbose
おや？何も変化していないぞ？
いや、変化しないことが正解なんだけど…。何もメッセージが出ていないのはちょっと気持ち悪いな。

ただ、クラスタ定義に1つエントリが追加されているのに気付いた。
(gemini) $ sudo crm configure show
--
前略
location cli-prefer-stonith2gemini stonith2gemini role=Started inf: gemini
後略
--
だ。
これを見ると、stonith2gemini は gemini で動く、という定義に見えるが…。

この状態でリソースを停止→起動してみるとどうなるだろうか？
(gemini) $ sudo crm resource stop stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
(gemini) $ sudo crm resource start stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
やっぱりリソースは cancer で動いているし、謎の location エントリは消えていない。
これが正しい動作なのだろうか…。

とりあえず、謎の location エントリは削除しておこう。
migrate で現れたステータスなので、消すのは unmigrate だ。
(gemini) $ sudo crm resource unmigrate stonith2gemini
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm configure show
元に戻った。

とりあえず、ダミーの stonith リソースは出来た。
一旦仕切り直して、IPアドレスのリソースを作ってみよう。

最初の方で警告が出たコマンドを実行してみよう。
(gemini) $ sudo crm configure primitive testip \
ocf:heartbeat:IPaddr2 \
params \
ip="192.168.55.155"
今度はすんなり通った。

状態を確認してみる。
(gemini) $ sudo crm configure show
(gemini) $ sudo crm status --verbose
(gemini) $ sudo crm_mon -A
testip リソースは cancer で動き出したな。
(何故か、cancer で優先的に動く。この辺りは何か理由があるんだろうけど、location 定義で制御するのが正しいんだろうな。)

とりあえず、cancer で IPアドレス が付与されているはずなので確認してみよう。
(cancer) $ ip address show
cancer で 192.168.55.155 が付与されたのが確認できた。

gemini から疎通確認。
(gemini) $ ping -c 5 192.168.55.155
ちゃんと応答がある。

では、cancer で動き出したリソースを、他のノード(今回は gemini しかいないので gemini )へ移動させてみよう。
(gemini) $ sudo crm resource migrate testip
(gemini) $ sudo crm status show
(gemini) $ sudo ip address show
(cancer) $ sudo ip address show
192.168.55.155 の IPアドレス は、無事に gemini に移動した。

この状態で configure を見てみると…
(gemini) $ sudo crm configure show
--
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
--
このエントリが追加されている。
これ、よく見てみると -inf: cancer となっていて、このリソースはもう cancer では動かせない、という定義だ。

pacemaker で primtive リソースとして定義されたリソースは、migrate させると、元のノード(先程の例では cancer )がダウンしたものとして、そのリソースは cancer には戻らないようになるようだ。
この辺り、クラスタ定義かリソース定義で変更出来ると思うけど、別途調査しないと分からない。

そのため、もう一回この testip リソースを migrate しようとすると、移動先のノードが無いため、リソース自身が停止してしまう。

もう少しこのリソースを元に調査をしたいが、今回はここまでにしよう。
(ちょっと長すぎたかな？)
一旦、リソースは元に戻しておく。
(gemini) $ sudo crm resource unmigrate testip

というわけで一旦終了。

アカン

ちょっと仕事が忙しくて、検証が進んでない。
ブログ掲載が遅れてるけど、まぁ誰も読んでないからいいか…。

pacemaker を入れよう

というわけで、HA クラスタソフトを入れる。
とは言え、ドレがいいのか分からないので、ここでは定番とも言える pacemaker にしよう。
対象は gemini / cancer だ。
$ sudo apt-get update
$ sudo apt-get --simulate install pacemaker
$ sudo apt-get install pacemaker

インストールが終わったら起動してみる。(基本設定してないけど…。)
(gemini) $ sudo systemctl start pacemaker
(gemini) $ systemctl --no-pager -l status pacemaker
Stonith 関係のエラーが出てる。

(gemini) $ ps -ef | grep pacemaker | grep -v grep
起動はしているようだ。

cancer も…。
(cancer) $ sudo systemctl start pacemaker
(cancer) $ systemctl --no-pager -l status pacemaker
あれ？Stonith 関連のエラーは出てこなかった…。

(cancer) $ ps -ef | grep pacemaker | grep -v grep
こちらも、起動はしているようだ。

pacemaker は、crm というコマンドを通して操作を行うようだ。
まずはステータスを見てみよう。
$ sudo crm status --verbose
どうやら、過去に構築した corosync を通して、ノード間の通信と Online 状態であることは確認できているみたいだ。
ただ、STONITHリソースが定義出来ていないので、他のリソースが起動できないよ、という警告が。っても、何のリソースも定義していないのだが…。

この後、Stonith を含む基本設定を施すことになるのだが、設定を施す前に、今どのような設定になっているかを確認しておこう。
クラスタ全体の Property 一覧は、crm の configure show_property で出力出来る。
$ sudo crm configure show_property
ただコレは、設定可能な項目の一覧なので、各項目にどのような値が設定されているか分からない。
設定されている値は、先程のコマンドの後ろに、設定項目名を入れると分かる。
例えば…
$ sudo crm configure show_property stop-orphan-resources
true
この stop-orphan-resouces というパラメータは、true が設定されている、ということだ。
一度、全部洗い出しておこう。

#	項目名	値	備考
1	stop-orphan-resources	true
2	dc-deadtime	20s
3	placement-strategy	default
4	symmetric-cluster	true
5	maintenance-mode	false
6	default-action-timeout	20s
7	node-health-yellow	0
8	start-failure-is-fatal	true
9	shutdown-escalation	20min
10	stop-all-resources	false
11	no-quorum-policy	stop
12	dc-version	1.1.14-70404b0
13	startup-fencing	true
14	stonith-enabled	true
15	pe-input-series-max	4000
16	stonith-action	reboot
17	pe-error-series-max	-1
18	is-managed-default	true
19	node-health-red	-INFINITY
20	remove-after-stop	false
21	crmd-transition-delay	0s
22	election-timeout	2min
23	node-health-green	0
24	node-action-limit	0
25	stonith-timeout	60s
26	enable-acl	false
27	batch-limit	0
28	pe-warn-series-max	5000
29	enable-startup-probes	true
30	stop-orphan-actions	true
31	default-resource-stickiness	0
32	cluster-recheck-interval	15min
33	cluster-infrastructure	corosync
34	crmd-integration-timeout	3min
35	stonith-watchdog-timeout	(null)
36	crmd-finalization-timeout	30min
37	have-watchdog	false
38	migration-limit	-1
39	load-threshold	80%
40	node-health-strategy	none
41	cluster-delay	60s

デフォルト値が分かったが、どの値が何を意味しているのか分からない。
おいおい調査していくことにしよう。

逆に言うと、何をどう設定すれば何が起きるのか分からない。
なので、今はデフォルトのママにして、必要に応じて修正していくことにする。

次回は、ゲストOS(leo) をクラスタサービスにしてみる。(出来るのか？)

HAクラスタに挑戦

今度は、Ubuntu を使った HA クラスタに挑戦してみたい。

と、その前に HA クラスタって何？ってところを整理しておきたい。
HA クラスタは、HA と クラスタ(Cluster) の2つに分割出来る。
それぞれ

• HA : High Availability(高可用性)
• Cluster : 束、房

を意味している。

そもそも、クラスタというのは「同じもの、同じようなものがたくさん集まって、1つの集合になっている」物を示すものだ。
良く引き合いに出されるのが、

• ぶどうの房
• バナナの房

等。
ぶどうは1つずつの粒がたくさん集まって、1つの房を形成していて、それ全体で「ぶどう」と呼んでいる。
バナナも同様、1本1本もバナナだけど、それが集まった房を指して「バナナ」と呼んでいる。
こういった感じで、同じもの、同じようなものが集まって1つの大きな集合を形成している姿を「クラスタ」と呼んでいる。
最近だと、ある特定のジャンルの専門家が集まって議論しているような姿をクラスタと呼んだりしていることも…。(医療者が集まっている姿を「医療クラスタ」とか、ガンダムに詳しいオタクを集めて「ガンダムクラスタ」とか…。)

まぁこういう感じで、「コンピュータを複数集めて、1つの大きなシステムを構成していること」を「コンピュータクラスタ」と呼んでいたりする。

で、もう1つの「HA」だけど…。
「高可用性」って言われても、何がなんだか良くわからない。
「可用性」が「高い」ということなんだけど、「可用性」ってナンだ？って。
これ、漢字をバラしてみると分かる。
「用いる(使用する)」ことが「可能」な状態を維持する「性能」。
これが「高い」ということ。
具体的には「いつでも使用することが出来る状態を維持していること」。逆に言うと「使用できない状態が少ない(短い)こと」。

システム全体のうち、一箇所壊れたってシステム的には稼働させることが可能な状態、ってことになる。
(構成によっては、一箇所どころか二箇所・三箇所壊れたって稼働させることが可能、ということも)

ちなみにITの世界では、「クラスタ」と言ったら、大抵はこの「HA クラスタ」を指す。

じゃぁ HA クラスタ以外にはどんなのがあるの？ということで、触りだけ。

• HPC(High Performance Computing)
  制御用コンピュータの配下に、たくさんのコンピュータを接続。
  制御用コンピュータが、複雑な処理や計算を分割、配下のコンピュータに分散処理あせることで、1台の性能では得られないパフォーマンスを得る。
  スーパーコンピュータが担っていた世界を置き換えているみたい。(タンパク質構造解析とか、画像(動画)解析とか、天気予報とか…)
• ロードバランシング型クラスタ
  ロードバランサ配下にたくさんのコンピュータを接続。
  アクセスを各コンピュータに振り分けることで、処理を分散させる。
  HPCとの違いは、配下のコンピュータは全て同じ機能しか持っていない、という点、ロードバランサはあくまで振り分けをしているだけで、大きな処理を分割しているわけではない、という点。
• 垂直分散型クラスタ(機能分散型クラスタ)
  システム的に、Web/Application/DB等に機能分割し、それぞれ専用のサーバを用意、各サーバ間で通信しながら、1つの大きなシステムを構成する。
  90年代後半から3層構造等と言われて、よく使用されている。

だ。(最後のは私が勝手に命名している。クラスタの1つに数えない人も多い。)

今回は、これらの中で HA クラスタに挑戦したいと思う。

というわけでマテ次回。

fcitx の profile か？

というわけで調べてみた。
全部を調べたわけではないが、まず引っ掛かったのは ~/.config/fcitx/profile というファイルだ。
こちらに、 IMName という設定がある。
これが、 gemini は mozc が指定されていて、cancer は fcitx-keyboard-jp が指定されている。
この違いだろうか？
これは恐らく、fcitx-configtool によって書き換えられたものと思われるけど、直接書き換えてみよう。
(cancer) $ vi ~/.config/fcitx/profile
--
IMName=fcitx-keyboard-jp
↓
IMName=mozc
--
この状態でも日本語入力出来ない。

一度ログアウト・ログインし直してから試してみる。
(再ログイン後、環境変数 XMODIFIERS を設定するのを忘れないように。)
それでもダメな(日本語入力出来ない)ようだ。

う～ん…。
一旦、gemini / cancer に teraterm でログインし、fcitx を起動、fcitx-configtool を比較してみるか。
$ export XMODIFIERS=@im=fcitx
$ fcitx
$ fcitx-configtool

う～む。どうやら設定が違うな。

• Default keyboard layout
• gemini : 日本語 - 日本語 (OADG 109A)
• cancer : Default
• Mozc Keyboard layout
• gemini : 日本語 - 日本語 (OADG 109A)
• cancer : Default

この違いだろうか…。
一度、cancer の設定を gemini の設定と同じにして、確認してみよう。
やっぱりダメだった…。

と、ここで gemini / cancer と taurus の /etc/default/im-config に差異があることが分かった。
gemini / cancer の /etc/default/im-config は同じだった。
どういうことだ？
って当たり前だ。gemini / canccer は Ubuntu 16.04、taurus は 17.04 だ。バージョンが違えばパッケージも違うわ。ボケてた。

ただ、virt-manager を起動しようとするたびに
Gtk-message: Failed to load module "canberra-gtk-module"
というメッセージが出てくる。
今の現象には関係無いけど、gemini / cancer にインストールだけしておこう。
$ sudo apt-get update
$ sudo apt-get --simulate install libcanberra-gtk-module
$ sudo apt-get install libcanberra-gtk-module
あれ？コレじゃないのかな？virt-manager 起動しても同じメッセージが出る。

…気を取り直して…
virt-manager 側の問題の可能性もあるので、一度、別のアプリケーションで試してみたい。
とは言え、gemini / cancer には X アプリケーションは全然入っていないので、何かインストールしよう。
テキストエディタの gedit がいいかな？
$ sudo apt-get --simulate install gedit
$ sudo apt-get install gedit

gedit で試してみたところ、やっぱり gemini の方は日本語入力出来て、 cancer の方は入力出来ない。
ということは、virt-manager の設定ではないということだ。

ラチが開かないので、taurus から sagittarius にログインして、同じように試してみた…。
なんと、日本語入力出来る！
特に fcitx を導入したわけでも無く、環境変数 XMODIFIERS を設定しただけだ。

う～ん。 cancer の設定がおかしいとしか思えないな…。なんだろう…？？？

一度、cancer の個人環境をクリアしてみよう。
(cancer) $ cd
(cancer) $ rm -rf .config
(cancer) $ rm -rf .dbus
(cancer) $ rm -rf .mozc
(cancer) $ rm -rf .cache
(cancer) $ rm .xinputrc
ここで一旦ログインし直し。
これで、もう一度確認してみよう。
…やっぱりダメだ…。

色々調べてみたんだけど、結局ダメだった。

出来れば解決しておきたかったんだけど、解決出来ないので今回は諦め。
もし何かヒントが見つかれば、また挑戦しよう…。

ちょっと不思議な事象が…

というわけで、taurus から gemini / cancer への日本語入力のテストを実施してみる。

taurus のコンソール(Remote Viewer や virt-manager を使用してくれぃ)からログインし、デスクトップ上でマウス右クリックからの「端末を開く」で2枚の端末を開く。
それぞれの端末で日本語入力出来ることを確認したら、ssh の -X オプションつきで gemini / cancer にログインしよう。
(taurus) $ ssh -X (ユーザ名)@(geminiのIP)
(taurus) $ ssh -X (ユーザ名)@(cancerのIP)

そしたら、gemini / cancer ともに fcitx と mozc が動いていないことを確認。
(gemini) $ ps -ef | grep -e fcitx -e mozc | grep -v grep
(cancer) $ ps -ef | grep -e fcitx -e mozc | grep -v grep

環境変数 XMODIFIERS を設定しよう。
(gemini) $ export XMODIFIERS=@im=fcitx
(gemini) $ env | grep XMODIFIERS
(cancer) $ export XMODIFIERS=@im=fcitx
(cancer) $ env | grep XMODIFIERS

設定されていることが確認できたら、 virt-manager を起動して日本語入力出来るか確認しよう。

というところでタイトルの「ちょっと不思議な現象が…」になる。
何故か、gemini から起動した virt-manager では日本語入力が可能で、cancer から起動した virt-manager では日本語入力が不可能なのだ。
両方共、fcitx / mozc は起動していないので、taurus のローカルで動いている fcitx / mozc を使っているはず。
gemini と cancer 、同じように作ったはずなんだが、何か違いがあるようだ。
この違いを追求しないと、ちょっと面倒なことになるかもしれない…。

というわけで、次回以降で調査を行おう。

Ubuntu Desktop 作ってみる

前回に引き続いて、日本語入力関連だ。
今までは Windows をメインマシンに据えて、そこから ssh で Ubuntu マシンにログイン、操作するというやり方だった。
この Windows の部分を、Ubuntu Desktop に置き換えてみようというのが今回の主旨。

まずは、Ubuntu Linux のサイトから、Ubuntu Desktop のメディアをダウンロードしよう。今回は 17.04 を入手した。

そしたら、仮想マシンの作成だ。
スペックは以下の通り。

• 仮想マシン名 : taurus
• ホスト名 : taurus
• IP Address : 192.168.55.135 / 24
• CPU : 4コア*1スレッド(4スレッド)
• メモリ : 4GB
• HDD : 72GB
• ソフトウェア等構成 : デフォルト
• ディスクレイアウト : お任せ＆LVM

実は、この blog には記載していないけど、過去に taurus は作っている。
あくまでテスト的な存在だったので、今はもう不要だ。
これをバッサリ削除して、完全に新規に作成する。

ざっくりインストールして、taurus 上で日本語入力が出来ることを確認しておこう。
あとは、個人的に FireFox は利用していないので、chromium-browser を導入しようと思ったが、google から Debian / Ubuntu 用の chrome がリリースされているようなので、それだけ入れておいた。

導入が終わったら、taurus にログインして、ssh で gemini / cancer にログインできることを確認しておこう。

次回から、日本語入力周りを再確認する。