sosreport-analyzer-ng の開発状況（2019-1-12）
sosreport-analyzer-ng ですが、v1.0.10 が最新となります。
v1.0.9 では、新たに加えた機能が原因で、うまく動いていなかったので、そこのところを直しました。
このように常に修正しているので、使用する場合は、最新バージョンを使ってください。
sosreport-analyzer-ng の開発状況（2019-1-8）
sosreport-analyzer-ng の、v1.0.8 を出しました。
多数のオブジェクトについて、初期化を忘れていた所があったので、ゼロで初期化しておきましたよ。
まだ直す所があるとすれば、直します。
ラーメン食べたいなぁ。
sosreport-analyzer-ng の開発状況（2019-1-5 その2）
sosreport-analyzer-ng の開発状況（2019-1-5）
sosreport-analyzer-ng ですが、v1.1.0 を出しました。
このバージョンでは、出力される 2つのファイル名の頭を、解析するディレクトリ名で揃えてあるので、後から見易くなっていますよ。sar-analyzer のグラフ機能は、まだ取り込んでいません。そちらは、しばらくお待ちください。
sosreport-analyzer-ng の開発状況（2019-1-3）
sosreport-analyzer-ng ですが、sar-analyzer, sosreport-analyzer を引き継ぐものという位置づけです。
現在のバージョンは、v1.0.2 になります。
ついに、sar-analyzer の機能を入れました。グラフ機能は、まだ生きになっていません。グラフ機能を使うのは、もう少しお待ちください。しなしながら、sar-analyzer の機能がつかえるようになったので、うれしいですね。
sosreport-analyzer-ng の開発状況（2018-12-30）
sosreport-analyzer-ng ですが、sar-analyzer, sosreport-analyzer を引き継ぐものという位置づけです。
現在のバージョンは、v1.0.1 になります。
このバージョンでは、ファイルへのリダイレクトを禁止し、./sosreport-analyzer-results ディレクトリに <dirname-time>.txt ファイルを書き出すようになっています。
sar-analyzer の機能は、まだ生きになっていません。sar-analyzer の機能を使うのは、もう少しお待ちください。
sosreort-analyzer の開発を止め、sosreport-analyzer-ng に移行します。
sosreport-analyzer-ng のバージョンは、v0.0.3 です。
ライブラリ化できたので、応用が広がります。
ライブラリは、/usr/local/lib にインストールされます。
本体は、/usr/local/bin にインストールされます。ダイナミック・リンクしているので、容量は、わずが 28 kbytes です。
現在のところ、sar-analyzer はまだ同梱できていません。
アイディアとしては、sosreort-analyzer コマンドにより、sar-analyzer の機能もできるようにします。同名のオブジェクトがあるので、それを修正します。
では、良いお年を。
Fedora 29 に、GNS3 環境を構築する
以前、Fedora28 のときに GNS3 の環境を作っていたのですが、Fedora29 になってから
何もしていなかったです。再び、GNS3 をやろうと思ったらエラーになっていたので、直したいです。
$ rpm -qa | grep gns3
gns3-gui-2.1.11-2.fc29.noarch
gns3-server-2.1.11-1.fc29.x86_64
gns3-net-converter-1.3.0-8.fc29.noarch
$ rpm -qa | grep qemu-system-x86
qemu-system-x86-3.0.0-3.fc29.x86_64
qemu-system-x86-core-3.0.0-3.fc29.x86_64
$ pip3 list | grep gns3
gns3-gui 2.1.11
gns3-net-converter 1.3.0
gns3-server 2.1.11
以下のサイトから、2.1.11 をダウンロードします。
https://github.com/GNS3/gns3-gui/releases
VirtualBox 版とします。以下のリンクとなります。
https://github.com/GNS3/gns3-gui/releases/download/v2.1.11/GNS3.VM.VirtualBox.2.1.11.zip
解凍します。
$ unzip GNS3.VM.VirtualBox.2.1.11.zip
$ ls -l "GNS3 VM.ova"
-rw-------. 1 xx xx 321134080 10月 1 01:17 'GNS3 VM.ova'
$ ls -lh "GNS3 VM.ova"
-rw-------. 1 xx xx 307M 10月 1 01:17 'GNS3 VM.ova'
「仮想アプライアンスのインポート」から、上記 ova をインポートします。
立ち上げると、以下のような表示が出ます。
-------------------------
GNS3 version: 2.1.11
VM version: 0.10.14
KVM support available: False
IP: 192.168.56.104
To log in using SSH:
ssh gns3@192.168.56.104
Password: gns3
Images and projects are located in /opt/gns3
Release channel: 2.1
-------------------------
ちなみに、/usr/bin/gns3 は ASCII TXT となっていますので、確認できます。
-------------------------
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'gns3-gui==2.1.11','gui_scripts','gns3'
__requires__ = 'gns3-gui==2.1.11'
import re
import sys
from pkg_resources import load_entry_pointif __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('gns3-gui==2.1.11', 'gui_scripts', 'gns3')()
-------------------------
立ち上げます。
$ /usr/bin/gns3
エラーになりました。
Edit --> Preferences で、パスを確認します。
Server のところを、/usr/bin/gns3 にしました。
GUI を閉じます。
もう一度、
$ /usr/bin/gns3
今度は立ち上がりました。
Server のところは、以下のようになっています。
-------------------------
/usr/bin/gns3server
/usr/bin/ubridge
192.168.56.1
3080 TCP
5000 TCP 10000 TCP
10000 UDP 20000 UDP
-------------------------
GNS3 VM のところは、以下のようになっています。
-------------------------
VirtualBox
GNS3 VM
8192 MB
4
-------------------------
sosreport-analyzer の開発状況（2018-12-30）
sosreport-analyzer ですが、最新バージョンは、v0.1.9 となっています。
面倒な検索を、設定ファイルにより簡素化できます。
そういえば、そのことを README に書いていなかった。。
なお、sar-analyzer も同梱されています。
別のプログラムにしていますが、make install で、2つともインストールされます。
良いお年を。
sosreport-analyzer の開発状況（2018-12-26）
sosreport-analyzer ですが、0.1.7 が現在最新のバージョンとなります。
messages や journal ログも検索表示することができます。設定ファイル、/etc/sosreport-analyzerd.conf で設定項目に、検索したい文字を、12個まで設定できますので、やってみてください。
Customer Obsession について
アマゾンの、Leadership Principle について考えてみる。
14 の Principle があるのだが、それぞれについて、ある意味、生き方の指標、指針にもなる事ができるのではないか、と考える。
まずは、Customer Obsession である。よく、日本語で「顧客第一」と呼ばれる、アマゾンの考え方の核ともいうべき Principle である。
東洋では、よく、「お客様は神様である」ということが言われ、そんな歌もあったのだから、日本人には馴染みがある言葉なのかもしれない。
「顧客」を、この「神様」というところまでもっていってしまうと、提供するサービスが無際限になってしまい、収拾がつかなくなる気がする。
提供するサービスは、明らかであるはずである。問題は、顧客が提供されるサービスに具体的に感じる「ギャップ」をどう埋めるか、というところなのではないだろうか。
サービスを提供する側としては、顧客が感じる提供するサービスにおける「ギャップ」を言われると、面食らうだろう。そして、いや、それはサービスにはない、と言うかもしれない。それは、ある意味しょうがないだろう。
しかし、そこで反省して、次は、もっと良いサービスを提供できるようにしたい、と考える事が必要であろう。次のサービス提供の機会は、明日かもしれない。昨日はこういったけれども、改善したので、今日は期待に添える、そのような姿勢を、"Customer Obsession” と言っていると思う。
sosreport-analyzer の開発状況（2018-12-14）
sosreport-analyzer ですが、v0.1.1 を出しました。
v0.1.0 には、ちょっとしたバグがあったので、それを直しました。
また、README に、ビルド方法も追記しました。
sar-analyzer は開発停止して、sosreport-analyzer に含めるようにしているので、
make install すれば、sosreport-analyzer と、sar-analyzer が両方インストールされます。
sosreport-analyzer では、好きな文字列を入れて検索できる機能があります。
設定ファイルは、/etc/sosreport-analyzerd.conf です。
新しくビルドしても、設定ファイルが存在していると上書きしません。
開発バージョンが進んで新しい機能が追加されると、設定ファイルにも項目が追加されています。make install した後に確認できる、新しい項目を含んでいる設定ファイルは、以下のファイルになります。
/usr/share/sosreport-analyzer/sosreport-analyzerd.conf.example
上記ファイルを、/etc/sosreport-analyzerd.conf としてコピーして使ってください。
sar-analyzer も、少し直したいとことろがあるのですが、お正月になるかな。
やっぱりお腹すいた。
sosreport-analyzer の開発状況（2018-12-12）
sosreport-analyzer の開発ですが、23項目を解析できるようになっています。
直近では、var/log/messages ファイルを解析できます。
デフォルトでは、error という文字を引っ掛けます。
error という文字は、設定ファイル /etc/sosreport-analyzerd.conf を編集することにより、変更できます。
sosreport-analyzerd.conf は、インストール時に sosreport-analyzerd.conf.example というファイルからコピーされます。
既に /etc/sosreport-analyzerd.conf が存在しているばあいは、コピーされません。
新しい機能を使いたい場合は、インストール時に更新されている、
/usr/share/sosreport-analyzerd/sosreport-analyzerd.conf.example から、
/etc/sosreport-analyzerd.conf に、コピーをして使ってください（root 権限が必要）。
とってもお腹すいたァ。。
AWS 上の EC2 サーバー上のトラブルを直した話
私は、5年程、以下のサイトを AWS で立ち上げています。
今回は、内容の話ではなくて、サーバー管理の話となります。
あるとき、実験をしたくなり、AWS のマネージメントコンソールからログインして、秘密鍵でサーバーに SSH 接続し、/etc/security/limits.conf のある値を、有り得ないぐらいの数値にしました。
次に、SSH接続したところ、一瞬ログインはできるのですが、すぐにクローズされてしまいました。何度やっても同じです。要すれば、サーバー（本番サーバーと呼びます）にログインできなくなってしまった、ということになりました。
さて、困ったな。原因もわからないけど、/etc/security/limits.conf に関連しているに違いない。このサーバーは、SELinux を有効にしています。SELinux に関連しているのかもしれない（実は、これに気づくのに、かなり時間がかかりました）。
EC2 には、AMI (Amazon Machine Image) というものがあります。一度、現在のサーバリソースを AMI としておけば、他のサーバマシンに /dev/sdf としてマウントできるので、中の設定ファイルをいじれると思いました。[1]
AMI を作成するのは簡単です。
EC2 Dashboard から、インスタンスを選択して、Actions --> Image --> Create Image とします。
AMIs をクリックすると、マシンイメージができています。
このマシンイメージを、別に仕立てておいたインスタンス（試験サーバーと呼びます）の /dev/sdf としてマウントすれば（マウントポイントは適宜決定）、中を覗けます。
今回は、このマシンイメージを、/mnt/backups にマウントしました。
less /mnt/backups/var/log/audit/auditlog | grep denied とすると、limits.conf が unlabeled_t にラベリングされているようでした。では、このマシンイメージの SELinux を、permissive にします。
/mnt/backups/etc/selinux/config を編集しました。
また、以下のコマンドを実行して、次回起動時に、リラベルされるようにします。
# touch /mnt/backups/.autorelabel
試験サーバーを停止します。
Volumes をクリックして、State が、in-use になっているもので、試験サーバーに紐づいているものを、Dettach します。すくなくとも、2つあるはずです。
次に、修正したマシンイメージを、本番サーバー（ID を事前に把握しておきます、なお、名前を付けておけばわかりやすいです）の、/dev/sda1 として指定します。
次に、本番サーバーを立ち上げます。
しばらく待ちます。
SSH 経由でログインできましたね。
ls -lZ /etc/security/limits.conf として、ラベルを確認します。
etc_t になっていますね。
では、/etc/selinux/config を編集して、permissive から、enabled に変更します。
# shutdown -r now あるいは、コンソールから、restart
お腹すいたァ。。
参考
[1]
Amazon マシンイメージ (AMI) - Amazon Elastic Compute Cloud
