仮想コンソール

仮想コンソール

直接筐体にログインする時などは便利なのか。 vmsareでは[Ctrl]+[Alt]+[space]を押した後[space]のみ離し、そのまま[Ctrl]+[Alt]+[F1～F5]で切り替わった。

ssh使うときは使っていない。

$ ps auxf | grep tty
xxxx      18404  0.0  0.0 103312   864 pts/3    S+   14:28   0:00              \_ grep tty
root      2712  0.0  0.0   4064   584 tty1     Ss+  09:43   0:00 /sbin/mingetty /dev/tty1
root      2714  0.0  0.0   4064   592 tty2     Ss+  09:43   0:00 /sbin/mingetty /dev/tty2
root      2717  0.0  0.0   4064   592 tty3     Ss+  09:43   0:00 /sbin/mingetty /dev/tty3
root      2719  0.0  0.0   4064   592 tty4     Ss+  09:43   0:00 /sbin/mingetty /dev/tty4
root      2721  0.0  0.0   4064   588 tty5     Ss+  09:43   0:00 /sbin/mingetty /dev/tty5
root      2723  0.0  0.0   4064   588 tty6     Ss+  09:43   0:00 /sbin/mingetty /dev/tty6

TTY

• ttyは実端末という意味。筐体にディスプレイつなげて直接ログインした時。
• vmwareなどでは、黒い画面を実端末として理解している。

$ tty
/dev/tty1

• ps のttyの項目にはtty(実端末)とかpts(仮想端末)とか表示される。
• psでtty項目が？なのは、標準入出力先の端末デバイスが指定されてないから。

PTS

ptsはsshなどの仮想端末。MACでの表示もこれだったような。

$ tty
/dev/pts/3

rloginなどを使ってsshでつなげて表示される黒い画面は、ディスプレイの中に仮想的にソフトウェアで作り上げているので仮想端末と呼ばれている。ttyは実端末という意味。

カーネルコンフィグレーション手順

カーネルコンフィグレーション手順

make mrproper

以前にソースを展開してコンフィグレーションで生成したファイルを全て削除。一回目だと必要ない。

make menuconfig

• .configファイルを作成する。
• 以前の設定を流用したい場合は
  • cp /boot/config-xxxxx (カーネルソースあるとこ).config
  • make oldconfig で今回での新しい設定しか聞いてこない。

make

• .configに従いコンパイル
• これでカーネルとモジュール両方をコンパイルして生成する。
• 個別にやる方法
  • make bzimage
  • make modules

make modules_install

モジュールを/lib/modulesにインストール

make install

カーネルを/boot下にインストール

メモ

bzimageは512KB以上のカーネルサイズに対応できる。zimageは512KB以下まで。 なのでbzimageが主流。

インクルードファイル

/usr/include

システムに標準的にインストールされているヘッダファイルの集まり。標準ヘッダファイル。

いろいろ

アプリケーション側に提供している

• /usr/include
  • glibcから提供のヘッダファイル
• /usr/include/linux
  • カーネルソースコード由来のヘッダファイル
• /usr/include/sys
  • カーネルから提供(システムコールなど)
• /usr/include/net
  • ネットワーク関連

運用コマンド

コマンド

ディレクトリ検索

find / -type d -name ".git"

ファイル検索

$ find ./ -type f -print | xargs grep 'hoge'

-type fはファイルだけを表示

grep -r hoge ./

ファイル名一括置換

find /aaa/bbb/img -type f -name "*jpg" | sed -e s/\.jpg// | awk '{print $1 ".jpg " $1 ".png"}' | xargs -n 2 mv

xargs -n 2 引数を２つとる。空白区切り。

yum

yum history info nagios

yum history list nagios

yum check-update

sort

オプションの指定がない場合は，行頭の文字を基準としてソートし，行頭の文字が同じ場合は，2番目，3番目，n番目の文字を次々に比較する。 デフォルトだと辞書順。数字も辞書順。

• -n

  • オプションを付けると数字は数値としてソートしてくれる。数字でないものは辞書順

• -t separator

  • ソートの区切りとしてseparatorを使用する。separatorが指定されない場合は空白

• -k 数値 or -k数値

  • ソート・キーの場所を設定する。ただし，先頭は1となる

• -r

  • 逆順にソートする

sort コマンド | コマンドの使い方(Linux) | hydroculのメモ

uniq

連続した行を一つにまとめる 連続していない離れた重複行も削除したければ、sortコマンドコマンドで予めソートする必要がある。その代わり順番は保存されない。

$ cat foo.txt | sort | uniq

uniq コマンド | コマンドの使い方(Linux) | hydroculのメモ

head

デフォルトで先頭の10行

• head -20
• head -n 20

lsof

ファイル名指定

lsof -f -- ファイル名

ファイルシステムにアクセスしているプロセスを発見する

lsof +f -- マウントポイントorデバイス

du

du -s /* | sort -rn | awk '{print $2}' | xargs du -sh

組み合わせ

cat /etc/ntp.conf | sed 's/#.*//g' | cat -s | grep '^server' | awk '{print $2}'

cat iplist | awk '{print $1}' | sort | uniq | wc -l

cat ip_list | awk 'match($0,/\".*\"/) {print $1}' | sed -e "s/\"//g" -e "s/,//g"

tr

tr 変換対象の文字 変換文字 対象ファイル

cat /etc/ services | grep http | tr '\t' ' ' | grep ' 80/'

grep

# 後ろ4行
cat /etc/nagios/servers/elasticsearch1.cfg | grep 'Eth0 Traffic Usage' -B4
# 前4行
cat /etc/nagios/servers/elasticsearch1.cfg | grep 'Eth0 Traffic Usage' -A4
# 前後4行
cat /etc/nagios/servers/elasticsearch1.cfg | grep 'Eth0 Traffic Usage' -C4
# AとB両方指定可能
cat /etc/nagios/servers/elasticsearch1.cfg | grep 'Eth0 Traffic Usage' -B2 -A1

正規表現でマッチした箇所のみ表示

grep -o '[0-9]\{2\}/.../2017:[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}' access_log

脆弱性パッチ対応

過去のCVE対応アップデートがわかる

$  rpm -q --changelog glibc | grep CVE
- Fix CVE-2015-8779 glibc: Unbounded stack allocation in catopen function
- Fix CVE-2015-8778 glibc: Integer overflow in hcreate and hcreate_r
- Fix CVE-2015-8776 glibc: Segmentation fault caused by passing
- CVE-2014-9761: Fix unbounded stack allocation in nan* (#1358014)

kernel-devel

kernel-develのバージョンが合わない場合、kernelのバージョンが低いことが多いのでまずはkernelをupdateすれば、yum install kernel-develでシステムのバージョンとあったものがインストールされる。

疑問

yum install kernel-devel　などした時にインストールするパッケージが現在のカーネルのバージョンと異なる時があったので、前述のyum updateを実行すればいいかと思ったが、yum update する対象がなかった。なんでだろう。

デバッグ情報取得

概要

gdbでデバッグした時のメモ。

環境

Vagrant CentOS6.8 on Mac

デバック情報(debuginfo)

各パッケージにはデバッグ情報が付いてこない。よって別途、デバッグ情報をインストールする必要がある。デバッグ情報とはシンボル情報やソースコードで、GDBなどのデバッカはバイナリの命令とソースコードを紐付けてくれる。デフォルトでデバッガは機械語から逆アセンブラしてくれて、アセンブラレベルでデバッグはできるが、やはりC言語でデバッグしたいのでとても便利。

デバッグ情報インストール

man debuginfo-install

NAME
       debuginfo-install

SYNOPSIS
       debuginfo-install package

DESCRIPTION
       debuginfo-install is a program which installs the RPMs needed to debug the specified package.  The package argument can be a wildcard, but will only
       match installed packages.  debuginfo-install will then enable any debuginfo repositories, and install the relevant debuginfo rpm.

EXAMPLES
       Download and install all the RPMs needed to debug the kernel RPM:
              debuginfo-install kernel

debuginfo-install パッケージ名　でデバッグ情報のパッケージをインストール。

gcc -g　などでコンパイルすれば、glibcの中もCのソースコードでデバッグできる。

既存のバイナリ

既存のバイナリのパッケージに対しては、ソースからビルドし直せばソースコードへのリンク付きでバイナリが生成されるのでソースコードレベルでデバッグできるようになるようだ。

カーネル

カーネルのdebuginfo導入方法

yum install kernel-debuginfo debuginfo-install kernel

カーネルリポジトリ

概要

Linuxカーネルのgit リポジトリの自分メモ。 よくわかっていないので間違っていることばっかりかも。 随時追記予定。

kernelnewbies

KernelBuild - Linux Kernel Newbies

カーネルをgit cloneする

バージョンの付け方

カーネルのバージョン2.6系とそれ移行、メインツリー、stableツリーでバージョンの付け方がことなる

2.6系

メジャーバージョンが増えていく。

• git tagで表示されるの(リリース毎にタグ付けされている)は2.6.11から。これより前はgitではなくほかのバージョン管理システムで管理していないのでみれない？

2.6系

A.B.C.D

A: メジャー番号
B: マイナー番号
C: リビジョン番号(機能追加で更新)
D: 修正リリース  (修正パッチリリースで更新)

A.B.C　　メインツリーのバージョン //3桁目が伸びる 2.6.23 → 2.6.24 → 2.6.25
A.B.C.D　stableツリーのバージョン //4桁目が伸びる 2.6.23.1 → 2.6.23.2 → 2.6.23.3

3系

3系からカーネルのバージョン番号の付け方の規則が変更された

• 3系からは二桁目までが対象。

3系以降

A.B.C

A :メジャー番号
B: マイナー番号
C: 何かしらの変更(修正パッチリリース、機能追加など？)

A.B　　メインツリーのバージョン //2桁目が伸びる  3.1 →　3.2 → 3.3
A.B.C　stableツリーのバージョン //3桁目が伸びる  3.0.1 →　3.0.2 → 3.0.3

参考

バージョンについて

第23回 Linux-3.0に寄せて：玩式草子─ソフトウェアとたわむれる日々｜gihyo.jp … 技術評論社

1つめの数字（"A"）を「メジャーバージョン番号」，2つめの数字（"B"）を「マイナーバージョン番号」，3つめの数字（"C"）は「リビジョン番号」，あるいは「パッチ番号」と称しています。プロジェクトによってはさらに数字を追加してA.B.C.Dというスタイルを採用することもあり，Linuxでも2.6系では2.6.39.2のように4つの数字でバージョンを管理しています。"C"以下の部分は，バグの修正ごとに更新したり，ある程度変更箇所がたまった時点で更新したりと，プロジェクトにより千差万別ですが，以前のバージョンと互換性を損なわないレベルの変更を区別するために用いるのが一般的です。

mag.osdn.jp

3.0以降では3桁目は安定版リリース用となるため、最新のカーネルは「3.0.0」ではなく「3.0」となり、次期版は「3.1」となる。安定版は「3.0.1」、「3.0.2」……と続くことになる。

ディストリビューション

kernel-2.6.32-642.el6.x86_64

2.6.32 :バージョン番号 カーネルのバージョン

642.el6:リリース番号 パッケージに修正があれば番号が増加していく。el6はEnterprise Linux 6という意味。

ツリー

mainline

• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

• 開発版(RC)を経る

  • linux-4.11-rc1 ~~~ linux-4.11-rc8 →　linux-4.11 → linux-4.12 ~~~ linux-4.17

• リーナスさんがリリース

linux-stable

• https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/

• メインツリーでリリースされたカーネルに対して、何かしら修正が加えられリビジョンが増えていく。メインツリーの番号+番号。修正後はこのツリーで管理。担当するメンテながバグフィックス。longtermとなった安定版以外は比較的早くEOL

LTS

• Long-term support (LTS)はこの中から選ばれる。
• 現在のLTSの一覧 The Linux Kernel Archives - Releases 2.6系はない？

• longterm版は約2年間、バグフィックスのサポートあり

• ディストリビューションのカーネルはディストリビューションのコミュニティ？でカーネルのサポートされているみたい。なのでこのlongtermに関係なく、プロダクト毎のサポート期間があるのでそれを見る必要がある

longterm以外は意外と早くリリースがなくなる。次の2桁目が大きくなってそっちに移っていく様子 (バグフィックスのサーポート終了)

longtermになっているブランチは3桁目の番号が大きい。↓

例 各LTSのバージョン

longterm:    4.4.39
longterm:   4.1.37
longterm:   3.18.46
longterm:   3.16.39
longterm:   3.12.69
longterm:   3.10.104
longterm:   3.4.113
longterm:   3.2.84

タグ

mainlineもstable-treeもリリースごとにタグ付けされているみたい

git tag

v4.8.10
v4.8.11
v4.8.12
v4.8.13
v4.8.14
v4.8.15

ブランチ

linux-stableでブランチを確認してみた。メジャーに+yが付与。 うーんこれは一体

$ git branch -a

  remotes/origin/linux-2.6.34.y
  remotes/origin/linux-2.6.35.y
  remotes/origin/linux-2.6.36.y
  remotes/origin/linux-2.6.37.y
  remotes/origin/linux-2.6.38.y
  remotes/origin/linux-2.6.39.y

  remotes/origin/linux-3.9.y
  remotes/origin/linux-4.0.y
  remotes/origin/linux-4.1.y
  remotes/origin/linux-4.2.y
  remotes/origin/linux-4.3.y
  remotes/origin/linux-4.4.y
  remotes/origin/linux-4.5.y
  remotes/origin/linux-4.6.y
  remotes/origin/linux-4.7.y
  remotes/origin/linux-4.8.y
  remotes/origin/linux-4.9.y

mainlineで確認してみた ブランチない。マスターブランチのみ。

 (master)$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

linux-next

• kernel/git/next/linux-next.git - The linux-next integration testing tree

参考

d.hatena.ne.jp

まとめ

上からgit cloneする。