カーネルリポジトリ

概要

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

nagios check_snmp

概要

nagiosのnrpeを用いたcheck_snmp監視を実施した際のメモ。

差分 --rate

ネットワークの量を求めるにはある時点とある時点の差分が必要。ある時点だけ高いなどあるからだと思われる。 SNMPはカウンタを用いて差分を求めるようにしている様子。カウンタはネットワークの総量との認識。

--rate-multiplier 8

計算の間隔を8秒にする。8秒にすることで単位をbpsにすることができる。

わかりにくいところ

差分を求める際に、ある時点からある時点への時間が10分だとした時に--rate-multiplier 8だと8秒ずつで区切って計算された 値が平均され取得されると思われる。

コマンドラインから試してみた

だいたい同じ値になるので、そうではなかろうか。

30秒
SNMP RATE CRITICAL - *26882812.12* | IF-MIB::ifHCOutOctets.3=26882812.12;5000000;10000000;

300秒
SNMP RATE CRITICAL - *27400005.63* | IF-MIB::ifHCOutOctets.3=27400005.63;5000000;10000000; 

Kibana5

概要

kibanaを5にUpdateした際にアクセスが出来なかったときのめも。

/etc/kibana/kibana.yml

netstat

netstat -tnpa

まとめ

kibanaにかぎらずブラウザからアクセスできずアプリケーションのログも出ない場合 netstatで正常にIPアドレスがアプリケーションにバインドされているかを確認すること。大事なり。