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

linux-stable

LTS

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

参考

d.hatena.ne.jp

まとめ

上からgit cloneする。

CentOSの外部リポジトリの設定

概要

CentOSにて外部リポジトリを追加した時のメモ

公式wiki

AdditionalResources/Repositories - CentOS Wiki

ここを参照して公式に認定?しているリポジトリを選ぶとよさそう。

よって、有名なRPMForgeでも、もう使っては駄目。

RPMForge/RepoForge - This is a dead project. Not maintained. DO NOT USE.

Epel

公式wikiから辿って、rpmをダウンロードしてインストールするとEpelリポジトリが使える。 Epelに限らずこの方法で追加していけそう。

http://fedoraproject.org/wiki/EPEL

カーネルのソースなど

HowTos/I need the Kernel Source - CentOS Wiki

↑で書かれている下記URL(Cent6系の場合)で直接kernelソースパッケージをwgetでダウンロードするか、

下記URLが記載されたリポジトリを自分で作成する。 この場合、カーネルに限らず、このURLの中にあるソースパッケージをyumでダウンロード出来るはず。

nagiosとVirtualHost

概要

nagiosのcheck_httpを使ってApacheの監視をした時のメモ。

check_http

apacheでVirthalHostの設定を入れた場合、リクエストに含まれるHostsヘッダーを参照し、「ServerName」と一致するブロックを探しだす。 よって、check_httpの引数にドメインを指定する場合はHostsヘッダーが必須となり、Hオプションを使用しないと正常に動作しない。Hオプションでドメインを指定するとそれがHostsヘッダーの値となる。 Iオプションの場合だとHostsヘッダーを使用しない。

参考

www.adminweb.jp

デフォルトゲートウェイ

概要

ネットワークを勉強したときのメモ。

デフォルトゲートウェイ

例えばIPが192.168.100.90のホストにてデフォルトゲートウェイに192.168.0.1など、異なるセグメントのIPを指定することはできない。 当たり前か。。泣 よって、セグメントが異なるホストがいれば、GWは異なる。

標準エラー出力

概要

標準エラー出力のメモ

2>&1

cat aaa > bbb.txt 2>&1

cat aaa > bbb.txtだと標準出力だけファイルに cat aaa 2> bbb.txtだと標準エラー出力だけファイルに

標準エラーも標準出力も(この場合ファイルに)出力したい場合などに利用。

デフォルトはどっちもシェルがその時に結びついている端末

参考

www.int-infra.net