Fedora20 テキスト インストール

マシンスペックの向上した現在、そんなに出番はないと思いますが・・・
Fedora20をテキストモードでインストールしようというのが今回の内容です。

最初にこのモードでインストールする場合の注意点を2つあげておきます。
これが許容できない場合は、他の手段でのインストールを検討してください。

1. ディスクレイアウトをカスタマイズできない　
2. インストール完了後、コンソールのKEYMAPが英語になる

         ※コンソールのKEYMAPを変更したい場合は、この記事の一番最後を見てください

テキストインストール

それでは早速インストールをしていきましょう。

1．インストールが開始されたら画面下部の「Press Tab for full configuration options on menu items.」のメッセージに従って、TABキーを押します。ブートオプションとして、textを指定します。

2．次に、最初に注意としてあげたディスクのパーティショニングについての情報が表示され、textモードではなくvncモードでのインストールを代替案として提示されます。ここではテキストモードでインストールする為、”2”と入力します。
　※vncでのインストールは、こちらの記事を参照してください

すると画面下部にInstallationメニューが表示されます。
項目的には１）～７）まであり、設定が必要な箇所には”!”マークがついていて、これを全て設定済み（”x”マーク）にしていきます。






3．各項目の設定

※画面の一番下に「Please　make your choice from above ['q' to quit | 'c' to continue | 'r' to refresh]:　」とあるように、もし項目をちゃんとセットアップしたのにもかかわらず”x”マークがつかない場合は、一度”r”キーを押してrefreshを実施してみてください。


1）Timezone Settings
上記の画面から1と入力後、Asiaの6　→　Tokyoの71と選択しました。

2）Installation source
2と入力後、ここではCD/DVDの1と選択しました。

3）Software selecttion
3と入力後、ここではMinimal Installの12　→　continueのcと進めました。

4）Installation Destination
4と入力後、c  →　Use All Spaceの2　→　c　→　Standard Partitionの1　→ c　と進めました。

5）Network configuration
DHCPでIPが取得できると最初から”x”マークがついていますが、固定IPを設定するには5と入力後

- Set hostnameの1を入力後、サーバのホスト名を入力
- Configure device xxxxの2を入力後、必要箇所を一つづつ入力

で最後に c → ｃ と進めました。

6)Root password
6と入力後、任意のパスワードを2回入力しました。

7）User creation
7と入力後、一般（作業用）ユーザを作成しました。
　- 3）Username でユーザ名を
　- 4) Use password でパスワード認証を有効に
　- 5) Passwordで、ユーザのパスワードを設定
　- 6) Administratorの箇所にチェックを入れることでsudoの設定が有効になります


以上で、下記のように全ての項目にxがついた状態でcを入力するとインストールが開始されます。

そして、「Installation complete. Press return to quit」と表示されたらインストールは完了です。
表示されたとおりRetrunキーを押し、インストーラーを終了させてください。

コンソールのKEYMAPを変更するには

ここでは、jp106へ変更してみます。
※変更が完了するまでは、コンソールは英語のKEYMAPになっているので、可能であればPuttyなどのSSHクライアントから作業を実施した方が良いかもしれません


1. /etc/vconsole.confの修正

以下の記述だけにします。

KEYMAP="jp106"

2. Setup Virtual Consoleの再起動

# systemctl status systemd-vconsole-setup.service
systemd-vconsole-setup.service - Setup Virtual Console
   Loaded: loaded (/usr/lib/systemd/system/systemd-vconsole-setup.service; static)
   Active: active (exited) since Sat 2014-06-28 16:40:14 JST; 27min ago
     Docs: man:systemd-vconsole-setup.service(8)
           man:vconsole.conf(5)
 Main PID: 72 (code=exited, status=0/SUCCESS)
Jun 28 16:40:14 test.examp.com systemd[1]: Starting Setup Virtual Console...
Jun 28 16:40:14 test.examp.com systemd[1]: Started Setup Virtual Console.
#
# systemctl restart systemd-vconsole-setup.service

以上で、コンソールのKEYMAPも日本語になっているはずです。

Fedora20 VNC経由でインストール

タイトルのとおり、Fedora20をVNC経由でインストールしようというのが今回の内容です。

インストールするサーバでの作業

1．インストールが開始されたら画面下部の「Press Tab for full configuration options on menu items.」のメッセージに従って、TABキーを押します。

するとブートオプションが入力できるようになるので、ここでvncと入力後、Enterを押します。

2．多少時間はかかりますが、下記の図のようにvnc clientから接続する情報が提示されるので、メモをしておきます。

クライアントからの作業

ここからは、VNC Viewerのインストールされている端末から作業を継続します。
※私の場合は、Windows7+Chrome+拡張機能（VNC Viewer for Google Chrome）でアクセスしました

VNC Viewerを起動するとインストールするサーバのIPアドレスをきかれるので、サーバでの作業2．のところでメモした情報を入力して、[Connect]をクリックします。

すると、以下のようにインストーラーが立ち上がるので、後は通常どおりインストールを進めます。

Linux Tips： コンソールでの文字化けを解消するには

久しぶりにDebian系ディストリのインストールを行った。

その際、インストール初期に聞かれるLanguageの画面で”日本語”を選択し、インストールを完了させました。

次に、コンソールを利用したのですが、manを見れば文字化け、apt-get updateをすれば表示されるメッセージは文字化けと困った事に。

原因は、日本語でセットアップしたことにより、localeが以下のように設定されてしまうから。

→コンソールで、ja_JP.UTF-8の表示は基本的にまともにできない

　（いまでもkonとかあるんだろうか　→　さがしたらkon2とかでてきますね）

~$ locale
LANG=ja_JP.UTF-8
LANGUAGE=
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=
$

前置きが長くなりましたが、この状態を回避しようというのが今回の内容です。

回避策

1．インストール初期のLanguageをEnglishにしてインストールし直す

時間が許せばこの方法が、一番ベストだと思います。

これでlocaleは、en_US.UTF-8あたりに設定されるので、基本的に文字化けしません。

※サーバ用途では、日本語による表示を必要としないのなら、不必要なパッケージのインストールを防ぐという観点から、これを特にお勧めします

2．コンソールにログイン後、環境変数を設定する

ログイン後、以下のコマンドを毎回実行してから作業を実施します。
※これが面倒な場合は下記の3．を試してください。

$ export LANG=C

3. 作業する＄TERMにあわせて＄LANGを自動的に選択させる

以下の記述を~/.bashrcあたりにすることによって、＄TERMの種類により、ログインする環境にあわせた＄LANGを設定する事ができます。

※コンソールはCの表示にし、それ以外（例えばxtermやWindows上のPuttyなど）は日本語での表示を可能にします

case $TERM in
   linux)
        LANG=C
        ;;
   *)
    LANG=ja_JP.UTF-8
    ;;
esac
export LANG

（備考）

Redhat系の場合、この3．と同様の設定が、Fedoraだと8あたりから、CentOSだと5から/etc/profile.d/lang.shとして用意されています

Fedora20 インストール画面がまともに表示されなかったら

（自分のところでは、VMware環境で100%なってしまいますが）インストールを開始してパーティショニングするところで、下の画像のように、画面の表示がおかしくなり困った事はないでしょうか？

この状況を回避しようというのが今回の内容です。

回避策

インストーラーのAnacondaで解像度を調整することにより回避する事ができます。

1．インストールが開始されたら画面下部の「Press Tab for full configuration options on menu items.」のメッセージに従って、TABキーを押します。

2．するとブートオプションを入力できるようになるので、ここに解像度を指定してやります。

　　ここでは、resolution=1024x768と指定しました。

結果、以下のように画面全てがまともに表示されるようになります。

（備考）

Anacondaのブートオプションには、その他に有用な（面白そうな）ものが結構あるので興味があれば調べてみると良いかもしれません。

https://fedoraproject.org/wiki/Anaconda_Boot_Options?rd=Anaconda/Options

CentOS6（RHEL6）でクラッシュダンプを取得する SSH経由で他のホストへ出力

前回の続きで、タイトルのとおりSSH経由でダンプをリモートのホスト上にはかせてみようというのが今回の内容です。

※評価は、CentOS6.5（x86_64）でメモリ2GBを搭載したマシンを2台用意して行っています
※また、2台のIPアドレスは下記のとおりです

　ダンプを受け取るリモート側のホスト：192.168.233.21

　ダンプをはくホスト　　　　　　　　：192.168.233.12

ダンプを受け取るリモート側での作業

ダンプをはく側からSSH経由でアクセスしてくるので、事前にダンプ用ユーザ（下記の例ではkdumpユーザ）の作成とそのユーザでデータを保存できる領域（下記の例では、ホームディレクトリをとして/kdumpを指定）を作成します。

# useradd -m -d /kdump kdump
# grep kdump /etc/passwd
kdump:x:502:502::/kdump:/bin/bash
#

ダンプをはく側での作業

1. /etc/kdump.confの編集

※リモート側で準備したkdumpユーザの権限で、（SCPを使って）データ転送を実施します
※デフォルトで/var/crash配下にデータを転送しようとしますが、その際のアクセス権に注意する必要があります
→pathで任意の場所を指定すれば、デフォルト以外の場所に転送可能なので、下記の例ではリモート側で準備した/kdump配下に転送します

 net kdump@192.168.233.21
 path /kdump
 core_collector makedumpfile -c --message-level 1 -d 31

2. kdump用SSH鍵の登録
以下のようにkdumpスクリプトを使って、ダンプをはく側での秘密鍵と公開鍵の生成とダンプを受け取るリモート側への公開鍵の登録までを実施します。

# /etc/rc.d/init.d/kdump propagate
Generating new ssh keys... done.
kdump@192.168.233.21's password:          ←★パスワードを入力
/root/.ssh/kdump_id_rsa has been added to ~kdump/.ssh/authorized_keys on 192.168.233.21
#

（注意）

ダンプを受け取るリモート側で、SSHのパスワード認証が有効になっている必要があります
→鍵認証のみで運用している場合は、鍵登録に失敗しますが、その際は
  /root/.ssh/kdump_id_rsa.pubを手動でauthorized_keysとして登録します

3.変更の適用

# /etc/rc.d/init.d/kdump restart
Stopping kdump:                                            [  OK  ]
Detected change(s) the following file(s):
  /etc/kdump.conf
Rebuilding /boot/initrd-2.6.32-431.1.2.0.1.el6.x86_64kdump.img
Starting kdump:                                            [  OK  ]
#

動作確認

ダンプをはく側でkernelをクラッシュさせて、リモートで受け取る側にダンプが出力されているか確認します。

# ls -l /kdump/192.168.233.12-2014-03-24-17\:55\:07/
total 19884
-rw-rw-r-- 1 kdump kdump    85833 Mar 24 17:55 vmcore-dmesg.txt
-rw-rw-r-- 1 kdump kdump 20274689 Mar 24 17:55 vmcore.flat
#

CentOS6（RHEL6）でクラッシュダンプを取得する

OSが突然死するとログに手掛かりとなるような出力（判断材料）が意外な程なく、途方にくれる事が多いのですが、その対策としてダンプをはかせてみようというのが今回の内容です。

※評価は、CentOS6.5（x86_64）でメモリ2GBを搭載したマシンで行っています

クラッシュダンプを取得する為のセットアップ

CentOS6.5でクラッシュダンプを取得するには、kdumpサービスを利用します。

以下、その手順です。

1. 必要なパッケージのインストール

kdumpサービスを利用するには、kexec-toolsがインストールされている必要があります。

# yum install kexec-tools

2. メモリー使用量の設定

クラッシュダンプ用に割り当てるメモリ容量を設定します。

→通常、起動しているOSからはそのメモリ領域はないものとして扱われます（※下記の（備考）参照）

設定は、grub.confのkernelの行に”crashkernel”パラメータを渡すことで行いますが、

通常、最初から”crashkernel=auto”と指定されていると思います。

※CentOS6.5では、2GB以上のメモリが搭載されていればkdumpサービスが有効になっていなくても、自動的にメモリの割り当てだけは行われています

※autoで割り当てられたメモリ容量は以下のいずれかのコマンドで確認できます

 # cat /proc/cmdline

 # cat /sys/kernel/kexec_crash_size

※2GB未満の場合は、自動的に割り当てられることはないので、autoの箇所に128Mとじかに指定する必要があります

title CentOS (2.6.32-431.5.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-431.5.1.el6.x86_64 <中略> crashkernel=auto
        initrd /initramfs-2.6.32-431.5.1.el6.x86_64.img

(備考）====================================================

・2GBのメモリ搭載し、crashkernelの指定がない場合のメモリ容量

# cat /proc/meminfo
MemTotal:        2046588 kB
MemFree:         1867764 kB
Buffers:            7584 kB

     ・

     ・

・2GBのメモリを搭載し、crashkernel=autoの指定がある場合のメモリ容量

　→2GBからクラッシュダンプ用に割り当てられたメモリ容量が差し引かれて表示されます

# cat /proc/meminfo
MemTotal:        1914492 kB
MemFree:         1733792 kB
Buffers:            7568 kB

     ・

     ・

============================================================

3. 設定ファイル　/etc/kdump.confの編集

今回は、デフォルトのままで特に編集を行いませんでした。

4. kdumpサービスの起動と状態確認

# chkconfig kdump on
# /etc/rc.d/init.d/kdump start
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-431.1.2.0.1.el6.x86_64kdump.img
Starting kdump:                                            [  OK  ]
#

kdumpサービスが有効になったかは以下のコマンドで確認できます

# /etc/rc.d/init.d/kdump status
Kdump is operational
#
# cat /sys/kernel/kexec_crash_loaded
1
#

コアダンプの分析

コアダンプの分析を行うまでの手順は下記のようになります。

1. 必要なパッケージのインストール

デバッグ情報付きでビルドされたカーネルとcrashパッケージをインストールします
→現在running中のkernelに合わせてインストールします

# yum --enablerepo=debug install kernel-debuginfo-`uname -r` crash

2. kernelクラッシュ

今回は、下記コマンドで強制的にkernelクラッシュを発生させます

# echo c > /proc/sysrq-trigger

これで下記のように/var/crashディレクトリ配下にコアダンプが吐かれます。

# ll /var/crash/127.0.0.1-2014-03-17-17\:36\:44/
total 30292
-rw------- 1 root root 30929131 Mar 17 17:36 vmcore
-rw-r--r-- 1 root root    85835 Mar 17 17:36 vmcore-dmesg.txt
#

3. crashユーティリティの実行

# crash /usr/lib/debug/lib/modules/2.6.32-431.1.2.0.1.el6.x86_64/vmlinux \
> /var/crash/127.0.0.1-2014-03-17-17\:36\:44/vmcore

以下のようにプロンプトが戻っててきたら、各種コマンドで解析が実施できます。

→利用できるコマンドはhelpで確認できます

crash 6.1.0-5.el6
Copyright (C) 2002-2012  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/2.6.32-431.1.2.0.1.el6.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2014-03-17-17:36:44/vmcore  [PARTIAL DUMP]
        CPUS: 1
        DATE: Mon Mar 17 17:36:41 2014
      UPTIME: 00:41:54
LOAD AVERAGE: 0.10, 0.17, 0.08
       TASKS: 71
    NODENAME: kdump.example.com
     RELEASE: 2.6.32-431.1.2.0.1.el6.x86_64
     VERSION: #1 SMP Fri Dec 13 13:06:13 UTC 2013
     MACHINE: x86_64  (3192 Mhz)
      MEMORY: 2 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 4289
     COMMAND: "bash"
        TASK: ffff880037c20ae0  [THREAD_INFO: ffff880037aea000]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash>

rsyslog 制御文字の出力を抑制するには

今回は、$EscapeControlCharactersOnReceiveディレクティブについてです。

※評価はCentOS6.5(x86_64) + rsyslog-7.6.0で行っています

各種ログで以下のように"#0111"などの制御文字が出力され、ログが見にくいなと感じたことはありませんか？

Feb 20 23:31:48 host1 dovecot: auth: Debug: client passdb out: OK#0111#011user=user01@example.com
Feb 20 23:31:48 host1 dovecot: auth: Debug: master in: REQUEST#0113825991681#0111858#0111#01139e00ee36ea2ede7441004cca9bf81c7#011session_pid=1861

$EscapeControlCharactersOnReceive off

とrsyslog.confに設定することにより、この制御文字の出力を抑制することができます。

これですっきりと読みやすいログになりました。

Feb 20 23:33:26 host1 dovecot: auth: Debug: client passdb out: OK   1   user=user01@example.com
Feb 20 23:33:26 host1 dovecot: auth: Debug: master in: REQUEST  3685744641      1877    1       93338956ff312fddeea4e71e715cd44a      session_pid=1882