【技】bash更新@Centos 6.5

kooです。( ノ゚Д゚)ヨッ!
 
はい、一部では大騒ぎされていますね。Bashの脆弱性。
snap2359
 
当Blogも例にもれず、Bashは使用しておりました。
 
そんなわけで、脆弱性対策をば。
 
CVE-2014-6271とCVE-2014-7169の両方の対策が出来ていないとダメなのですが、
yumが使えます。
 

# yum list installed | grep bash

 
我が家の場合は、
bash.x86_64 4.1.2-15.el6_5.2
こうだったわけです。
 
んで、対策方法。

# yum clean all
Loaded plugins: downloadonly, fastestmirror, priorities, security
Cleaning repos: base extras rpmforge updates
Cleaning up Everything
Cleaning up list of fastest mirrors

※1行目を入力。 
 

# yum -y update bash
Loaded plugins: downloadonly, fastestmirror, priorities, security
Determining fastest mirrors
* base: www.ftp.ne.jp
* extras: www.ftp.ne.jp
* rpmforge: ftp.kddilabs.jp
* updates: www.ftp.ne.jp
base | 3.7 kB 00:00

base/primary_db | 4.4 MB 00:01

extras | 3.3 kB 00:00
extras/primary_db | 19 kB 00:00

rpmforge | 1.9 kB 00:00

rpmforge/primary_db | 2.7 MB 00:01

updates | 3.4 kB 00:00

updates/primary_db | 5.3 MB 00:01

21 packages excluded due to repository priority protections

Setting up Update Process

No Packages marked for Update

 
 お、更新されねぇー(ノД`)
 

# yum list installed | grep bash
bash.x86_64 4.1.2-15.el6_5.2

んで、↑このように、なるわけですが・・・・。
 
じつは、バージョン。
最新だったわけです。
 
Centosの場合、以下のVersionで対策済みとなります。
CentOS7
bash-4.2.45-5.el7_0.4

CentOS6
bash-4.1.2-15.el6_5.2

CentOS5
bash-3.2-33.el5_11.4
 
まぁ、yumが使えるので、楽ですね。

ツイートツイート

【悩】仮想環境が起動せんっ!

kooです。( ノ゚Д゚)ヨッ!
 
はい、どうも。
愛用の仮想環境がどうも起動しなくなりました。
recovery_mode1
HDDからの起動で、こんな画面までは進みます。
 
文字は小さいですが
左下に
と書いてあります。
ENTER押せば、Automatic boot in ● seconds…の表示をかっ飛ばして、
各種モジュールのLoadへ進むんです。
 
右下には、


とあります。
 
カーネルは2つも用意していなかったので、SHIFT+Rで進んでも、何も変化ありません。
怒られるだけです。それも赤文字で。
 
SHIFT+Oについては、何の反応もありません。
悲しい限りです。
 
では、正常起動のBootに進むと、
モジュールが がーっと流れて進みます。
index
こんな感じです。
 
普通は、こんな画面が出てくるはずです。
baiviet000155
 
でも、私の環境では出てきません。
DVDに最新の5.5を焼き付けて、上書きでもいいか。的なことを思って
Disk Bootすると、同じように
モジュール読み込まれた直後に
黒画面ブラックアウト現象発生っ! うえぇぇぇい。
 
 
原因はモニタかと思って、3枚ものモニタを交換して作業しましたが
全てだめ。
※まぁ、途中から止まるので、モニタはあくまでも気休め
 
じぇんじぇん、解決しましぇん。
 
どうしたら、いいんでしょうかねぇ~~~~~(´Д` )
 
BIOS回りの設定は、比較的強いです。
 

では、おやすみなさい ノシ
 

 

>

ツイートツイート

【忘】備忘録。yumが動かない(´Д` )

kooです。( ノ゚Д゚)ヨッ!
 
はい、どもす。
 
51xPiUkOI-L._AA300_
一応、Linuxサーバがあったりします。
それも複数台
 
そんな中、このBLOGも稼働中のサーバですが、
yumを叩いたら、応答なし子ちゃんになる事象が発生しました(´Д` )
 
普段使いのwin8.1もntpでLinuxサーバ使えばいいか。
と思って、
 

# yum -y update ntp

なんて、叩いたもんで・・・・・。

SSHの応答がなくなりました・・・ヽ(゚Д゚#)ノムキー
 
しゃーない。
治すか。

# cd /var/lib/rpm

んで。

# ls -al

んで、
__db.001
こんな感じのけっこうでかいファイルが見つかったりする。
私の場合、1~4までありました。
それぞれが、けっこうでかい。
 

# rm __db.00[1-4]

これで、まとめて削除。
えいやっ!
 

# rpm --rebuilddb -vv

リビルドぉ~(^^♪
 
大量にログが吐かれます。いやっほぉ~ぃぃ。

# yum clean metadata

 

# yum clean dbcache

 

# yum clean all

yum関連のファイルをきれいきれいして。

これで、完了です。
 

# yum -y update ntp

ようやく念願のntpをアップデートできます。

 
でも、出てきた答えは、

更新と設定されたパッケージがありません。

 
どうせ、そんなもんだよ。
 
はじめっから、Windowsの設定だけ変えておけばよかった・・・・・(´Д` )
 
ちゃんと、ntpとしても同期取れています。

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp-b3.nict.go. .NICT. 1 u 11 64 37 8.147 2.558 1.731
+ntp3.jst.mfeed. 133.243.236.19 2 u 7 64 37 6.990 3.325 1.827
ntp-a1.nict.go. .INIT. 16 u - 64 0 0.000 0.000 0.000

ちゃんちゃん。
 

 

 

ツイートツイート

【速】我が家のサーバちゃんのDisk速度

kooです。どもす( ノ゚Д゚)ヨッ!
 
はい。
Disk速度を計測してみました。

もちろん、Linuxです。
 
詳細はとりあえず、置いておきますが。
こんなコマンドを発行します。
要su
 
まずは、Diskのマウントポイントを確認します。
覚えていたら、飛ばしてください。

# df -h

 
んで、対象のDiskをみっけたら、
こうします。

# /sbin/hdparm -fTt /dev/sdb1

今回は、/dev/sdb1 を対象にやってみました。
 
結果は、こんな感じ。


/dev/sdb1:
Timing cached reads: 22982 MB in 2.00 seconds = 11513.80 MB/sec
Timing buffered disk reads: 394 MB in 3.00 seconds = 131.25 MB/sec

せっかくなので、他のディスクも比較してみます。
 

# /sbin/hdparm -fTt /dev/sda1

/dev/sda1:
Timing cached reads: 22108 MB in 2.00 seconds = 11068.54 MB/sec
Timing buffered disk reads: 500 MB in 1.25 seconds = 401.31 MB/sec

 
↑これが一番早かったです。
このDiskは、これを使っていたと記憶しています。

2TBで7000円しないんですから、安いですよねぇ・・・・・。
 
SSDにLinuxを入れていないので分からないですが、
ちょっと試したい気もします。どんなアホな速度が出るんでしょうかね。
こんなのとか。

こいつは、SATA3の転送速度限界に到達の史上最速SSDだそうです。
 
じつは、先日こさえたXEONサーバに
VMware vSphereを入れたHDDが一番早いという結論です。
サーバ実機に直接Linuxを入れた方が遅い。
 
まぁ、ファイルシステムを直接ext4で切ったか
LVMを組んでいるかという違いも大いに関係していると思うんですけどね。
 
ちなみに、↑のコマンドのオプションの意味は、
================================
-f 終了時に、デバイスのバッファキャッシュを同期、消去する。
この操作は、 -t および -T のタイミングでも実行される

-T ベンチマーク及び比較目的で、キャッシュ読み込みを測定する。
有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、
他にアクティブなプロセスがない状態で、この操作を 2,3回繰り返すべきである。
これは、ディスクアクセスなしに、Linuxのバッファキャッシュから直接読み出す速度を表示する。
これは、テスト環境下でのプロセッサ・キャッシュ・メモリの基本的な処理能力を測定するものである。
-t フラグが同時に指定された場合には、-Tの出力を元にした補正係数が-t 操作の結果に加味される。

-t ベンチマーク及び比較目的で、デバイス読み込みを測定する。
有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、
他にアクティブなプロセスがない状態で、この操作を 2, 3 回 繰り返すべきである。

これはデータのキャッシュがない状態から、バッファキャッシュを通して
ディスクを読み出す速度を表示する。
これは、ファイルシステムのオーバーヘッドなしに、そのドライブが Linuxで
どれだけ連続データ読み込み速度を維持できるかを測定するものである。
測定の正確さを上げたいのであれば、 -t の実行の間に BLKFLSBUF ioctlを使って
バッファキャッシュをクリアする。 -Tフラグが同時に指定された場合には、
-T の出力を元にした補正係数が -t 操作の結果に加味される
================================
まぁ、運用中のサーバで試した部分も大きいので
仮想環境との単純比較は出来ないですね。
仮想環境はまだまだ設定が入っていませんから。
 
にしても、Linuxの敷居がだいぶ低くなってきたよなぁ。
こんな簡単に無料でばんばんぶっ壊せるような
環境を作れるなんて、今からLinuxをはじめようって人には、いい時代なのかもしれない。
 
なんならAWSだってあるんですからね。

 

ツイートツイート

【直】ふぅ、AWS落ち着いたぁ。

kooです。どもす。
 
はい、どもす。
このBLOGとは、完全に別ものですが、もう1個のサーバ
AWSの方です。
 
どうも、午前4時頃にoom-killerという素敵な命令が発動して、
私のかわいいサーバちゃんを、がっつり停止状態に陥れてくれる。
※ちゃんと設定しておくことで、重要なプロセスにはoom-killerが発動されない。

→ ちゃんと設定していないから、重要なプロセスを叩き落す 素敵なoom-killerちゃん。
 
まぁ、そんなわけで、
oom-killerが発動する原因は何かなぁ。と探って行きました。
ぶっちゃけ、メモリとスワップを使い切ったら oom-killerが発動するんだから
そうなった時間から、何が動いたのかCronのlog見て確認。
 
あはははん。
 
まぁ、高負荷の原因はCACTIでした。。。。。

まぁ、AWSですから、Managementコンソールの方から負荷が見えるので、
cacti停めてもいいっか。って感じ。
 
んで、連動するものとしていろいろ停止できたので、
停止させちゃいます。
net-snmp-utils とか net-snmpとか rrdtoolもいらないので、停止。
 BLOGも完全にvktecに戻したので、mysqlもいらないから停止。ってな具合。
 
んで、↑の図のような状態になりました。
※9時間時差があるのは、仕様ですw
 
なんか、おかしい30分刻みで何かが動いて 負荷100%になってると思ったら、
clamavが、一生懸命 存在しないディレクトリをワシワシと探している。
そりゃ、負荷あがりっぱになるわ。
 
つぅわけで、書いたshも( ;´Д`) っ.。.:*・゜゚・ rmしてさようなら。
 
で、↑の図の 右側の状態を維持するようになりました。
CPU使い切るっつったって、ねぇ・・・・。
我が家のXeonよりは、そりゃ非力でしょうけど、AWSのCPUはけっこう頑張ってくれるので、
信頼しているんですが、コンソールでも処理落ちするくらいの高負荷状態ですからね。
限界やねん。それ。
 
まぁ、何にせよ 明日の朝 確認してみて
稼働状態とLogを見てみようっと。
 

ツイートツイート