投稿

CentOS7のキーマップ設定

CentOS7のキーマップ


設定されているキーボードの確認
# localectl status System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us

選択可能なキーマップの確認
# localectl list-keymaps | grep jp jp106

キーマップのセット
# localectl set-keymap jp106

確認
# localectl status System Locale: LANG=en_US.utf8 VC Keymap: jp106 X11 Layout: jp X11 Model: jp106 X11 Options: terminate:ctrl_alt_bksp
set-keymapで設定をすると virtual console (VC) と X11 の設定をまとめてやってくれるらしい。 各設定はそれぞれ以下の設定ファイルになっているので、手で編集してもOK。編集後はOS再起動が必要。
VC Keymap: /etc/vconsole.confX11関連: /etc/X11/xorg.conf.d/00-keyboard.conf

CentOS7のロケールの確認

CentOS7のロケールの確認


設定されているロケールの確認
# localectl status System Locale: LANG=en_US.UTF-8 VC Keymap: jp106 X11 Layout: jp

選択可能なロケールの確認
# localectl list-locales | grep ja ja_JP ja_JP.eucjp ja_JP.ujis ja_JP.utf8 japanese japanese.euc

ロケールのセット
# localectl set-locale LANG=ja_JP.utf8

確認
# localectl status System Locale: LANG=ja_JP.utf8 VC Keymap: jp106 X11 Layout: jp

設定ファイルは /etc/locale.conf


Dart Editor でアプリ実行時にエラーがでる

Dart というWebアプリ開発向けのプログラミング言語があり、ちょっと触ってみようかなと Dart Editor を使おうとしたら editor 上でアプリを実行しようとするとエラーがでる。

!ENTRY com.google.dart.tools.debug.core 4 0 2014-04-12 21:17:25.265 !MESSAGE Dartium output: /home/user/dart/chromium/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
環境は ubuntu 13.10 x86_64。
dart editor に含まれている chromium を動かすのに必要な libudev.so.0 が見つからんということらしい。

それっぽいものを locate コマンドで探してみる。
locate libudev.so 出力結果。
/lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.1.3.5
libudev.so.1 は libudev.so.1.3.5 のシンボリックリンク。というわけで、libudev.so.1.3.5 を使ってやればなんか動くんじゃないかと試しに以下のコマンドを打ってみる。
cd /lib/x86_64-linux-gnu/ sudo ln -s libudev.so.1.3.5 libudev.so.0
これで動くようになった。

[GCE] リージョン毎の遅延

イメージ
Google Cloud Platformもアジアリージョンができたことだし、リージョン毎にどれくらい遅延があるのか測ってみた。

各リージョンとゾーンでインスタンスを作る。あと、ネットワークのデフォルトの設定だと外部からのicmpは閉じているので事前に開けておく。テスト終わったら閉じるのを忘れずに。

各インスタンスにpingを投げた結果こんな感じ。
asia: 100ms くらいeurope: 400ms くらいus: 250ms くらい まあ当然ですが asia > us > europe の順に早い。asiaだと100msくらいなんで日本から普通に使えるレベルなのかなきっと。私ネットワーク詳しくないんでよくわかりませんが。


各インスタンスのping結果はこちら。

asia-a
ping -c 5 107.167.181.64 PING 107.167.181.64 (107.167.181.64): 56 data bytes 64 bytes from 107.167.181.64: icmp_seq=0 ttl=44 time=103.378 ms 64 bytes from 107.167.181.64: icmp_seq=1 ttl=44 time=93.266 ms 64 bytes from 107.167.181.64: icmp_seq=2 ttl=44 time=100.718 ms 64 bytes from 107.167.181.64: icmp_seq=3 ttl=44 time=97.191 ms 64 bytes from 107.167.181.64: icmp_seq=4 ttl=44 time=98.686 ms --- 107.167.181.64 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 93.266/98.648/103.378/3.398 ms
asia-b
ping -c 5 107.167.181.10 PING 107.167.181.10 (107.167.181.10): 56 data bytes 64 bytes…

Google Cloud PlatformのCompute Engine使ってみた

イメージ
Google Cloud PlatformのCompute Engineを使ってみた記事のまとめ。

Compute Engineをさわるために必要な事前準備はこちらの2つ。
Google Developers Consoleでプロジェクトを作成する。作成したプロジェクトの課金情報を登録する。 プロジェクト作成後の初期画面はこちら。

左側のメニューから「Compute Engine」をクリックすると初期化される。Compute EngineのAPIを有効化しているらしい。

初期化が終わるとこんな画面になる。


ここからいろいろ操作していきます。

Google Developers Consoleを使ったインスタンス操作(GUI)
Compute Engineでインスタンスを作成ディスクの作成インスタンスにディスクをアタッチファイアウォール ルールの追加VMのクローンの作成(失敗)スナップショットの作成スナップショットからインスタンスを作成インスタンスの負荷分散ネットワークの追加
Google Cloud SDKを使った操作(CUI)
Google Cloud SDKのセットアップgcutilをインストールインスタンスにssh接続リージョン毎の遅延

[GCE] ネットワークの追加

イメージ
ネットワークを追加する。

Compute Engineのプロジェクト作成時に default というネットワークが作成されるが、 10.240.0.0/16 というネットワーク決め打ちのようなので一旦削除して新規にネットワークを追加してみる。

「Compute Engine」→「ネットワーク」の画面で「新しいネットワーク」をクリック。

必要な情報を入れて「作成」をクリック。

以下の情報で作成してみた。
名前:networkアドレス範囲:10.0.0.0/8 ゲートウェイを空欄で作成すると、セグメントの先頭(xxx.xxx.xxx.1)が使われるようだ。

作成が完了すると一覧に表示される。


これでネットワークの作成は完了だが、デフォルトで外部からの全通信がブロックされるのでファイアウォール追加する。

作成したネットワークをクリックして、ファイアウォール ルールの項目で「新規作成」をクリック。

必要なルールを追加する。

追加したルールは以下。ポート番号を省略すると全ポート対象という扱いになる。

ルール1
名前:internalソースIPの範囲:10.0.0.0/8プロトコルとポート:tcp; udp; icmp ルール2
名前:sshソースIPの範囲:0.0.0.0/0プロトコルとポート:tcp:22
これで内部ネットワークは全通信許可、外部からはsshのみ許可というネットワークの作成が完了。


インスタンス作成時のネットワーク設定項目でこのネットワークを選択して作成することで利用できる。


【まとめ】
Google Cloud PlatformのCompute Engine使ってみた

[GCE] インスタンスの負荷分散

イメージ
ロードバランサを使ってみる。

「Compute Engine」→「負荷分散」で設定する。

「転送ルール」「ターゲットプール」「ヘルスチェック」の3つの設定項目があり、利用する場合は「ヘルスチェック」→「ターゲットプール」→「転送ルール」の順に設定を作成していく。
ヘルスチェックは省略可能。省略するとインスタンス障害時に切り離しといったことはできない。


とりあえず負荷分散できるかを見るためにまずはターゲットプールを作成する。画面上で「新しいターゲットプール」をクリック。

必要事項を入力して「作成」をクリック。

今回は以下の情報で作成した。
名前:lb-pool01地域:us-central1VMインスタンス:us-central1-a <tegetege-demo01>, us-central1-b <tegetege-demo03> ターゲットとするインスタンスは同一リージョンのものである必要がある。でもゾーンは異なっていても大丈夫らしい。作成が完了すると一覧に表示される。

次は、「転送ルール」で「新しい転送ルール」をクリック。

必要情報を入力して「作成」をクリック。

転送ルールは先ほど作成したターゲットルールを指定。
名前:lb-rule01地域:us-central1ターゲットプール:lb-pool01
作成が完了すると一覧に表示される。


インスタンスは以前httpdを立ち上げたものを使ったので、転送ルールの欄に表示されるIPアドレスにブラウザでアクセスするとapacheのテストページが見れる。インスタンスにログインして
sudo tail -f /var/log/httpd/access_log などとすると、両方のインスタンスにアクセスがきていることがわかる。


【まとめ】
Google Cloud PlatformのCompute Engine使ってみた