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
AWS で、フロントを Web サーバー、バックエンドに DB サーバーの構築方法（その1）
自分のアマゾンのリソースを、そのアカウント情報も含めて、アマゾンのベストプラクティスに合わせる取組をはじめました。
自分のアカウントは、今まで、root ログインであったものを IAM （AWS Identity and Access Management）を活用して、やりたい事象毎に IAM ユーザーを作成して、そのユーザー上で構築を行うように直しました。
過去 5年間にやっていたことは、言わば過去に自分でやっていた自宅サーバーをクラウド上にもってくる、という意味で、コミュニティ版の OS イメージを EC2 インスタンスとして立ち上げ、その上で PHP+PostgreSQL のサイトを立ち上げていただけでいた。まあ、これはこれでオンプレのサーバーをクラウドにおいて管理する、ということで意味があるかとはおもいますが、AWS のベストプラクティスを実践していたとは言えなかったです。
これを、あらたに VPC を作成し、Web サーバーと DB サーバーに分離して、前者を public subnet に、後者を private subnet に置き、internet-gateway、nat-gateway を作成して、DB サーバーをバックエンドに格納してセキュリティを高め、Web サーバーと DB サーバーとの通信は、あらたに作成する routing table により行うことにしてみます。また、EIP もあらたに作成して、インスタンス再起動によっても EC2 インスタンスは複数必要となりますが、最近数年間で、AWS は値下げを続けているそうで、実際、私が数年前、試しに複数インスタンスや EIP をつかってみた時の課金状況よりも、大分改善された（安くなった）と感じているので、AWS のベストプラクティスに従ってちょっとやり直しをしてみよう、ということです。
では、実際にやってみたことを、以下に記述します。
アカウントについて
root ユーザーでログインするときは、メールアドレスでログインして、パスワードを入れます。
IAM ユーザーを作成します。
このアカウントには、一つの環境しか作成しない方がいいです。
また、試験環境のアカウントと、本番環境のアカウントで、分けた方がいいです。
要すれば、アカウント単位で分けるのがいいということになります。
IAM ユーザーでログインする時は、ID + IAMユーザー名 + IAMユーザーのパスワード でログインします。
なお、IAM ユーザーに billing を閲覧させるには、以下のページの通りを設定してください。
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html?icmpid=docs_iam_console#tutorial-billing-step1
要すれば、web サーバーを public に置いて、プライベートに置いた db サーバーからデータを取得する、ということをやりたいです。
VPC をクリックします。
vpc を作成します（10.0.0.0/16）。
10.0.0.0/16 のネットワークを作成します。
4つの subnet を作成します。
subnet-xxxx-public-1a （10.0.11.0/24）
subnet-xxxx-public-1c（10.0.12.0/24）
subnet-xxxx-private-1a（10.0.21.0/24）
subnet-xxxx-private-1c（10.0.22.0/24）
それぞれ、north-eastern-1a,1c と紐づけます。
internet-gateway を作成します。
internet-gateway を、取得した EIP に紐づけます。
セキュリティグループを作成します。
web サーバー用のセキュリティグループを作成します。
ssh を、Myip にします。
http も追加します。
dbサーバー用のセキュリティグループを作成します。
ssh を、subnet-xxxx-public-1a のアドレス体系に許可します。
postgresql を追加します。これも、subnet-xxxx-public-1a のアドレス体系に許可します。
nat-gateway を、subnet-xxxx-public-1a （10.0.11.0/24） に作成します。
EC2 を Launch します。
community の fedora をチェックします。
atomic-host-upgrade-20181127 を選びます。
それぞれの項目を適切に選択します。
（あとで記述を追加する）
セキュリティグループ
ssh でログインします。
Elastic IP を指定しておきます。
そしてそれを、作成したマシンに紐づけておきます。
$ ssh -i xxxx.pem fedora@<EIP に紐づいたグローバルIP>
[fedora@ip-10-0-11-112 ~]$
上記のように、subnet に紐づいた名前が出てきますね。
- では、OS のアップグレードをします。
OS のアップグレード
# sudo su -
# atomic host upgrade
# systemctl reboot
- パッケージの確認をします。
# rpm -qa | wc -l
# rpm -q kernel
kernel-4.19.3-300.fc29.x86_64
- vim のインストールをします。
# atomic host install vim
- httpd のインストールをします。
# atomic host install httpd
- php のインストールをします。
# atomic host install php
ところで、インストールした後に、systemctl reboot としろ、となりますが、
これはなんなんだろう。これやらないと、rpm -qa | grep <package名>で
出てこないので、やっておきます。
# systemctl reboot
ところで、dnf も yum も入っていません。。インストール・アップデートは、atomic host コマンドを使うようです。あとでまた調べよう。。
ここで、ip a としてみます。
[fedora@ip-10-0-11-112 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
link/ether 06:20:e7:b2:4a:12 brd ff:ff:ff:ff:ff:ff
inet 10.0.11.112/24 brd 10.0.11.255 scope global dynamic noprefixroute eth0
valid_lft 3323sec preferred_lft 3323sec
inet6 fe80::420:e7ff:feb2:4a12/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:9e:5b:b1:77 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
なるほど、あくまで、ip は、10.0.11.112 という事なのですね。
# systemctl enable httpd
# systemctl start httpd
# systemctl status httpd
DB サーバーを Launch します。PostgreSQL をインストールします。
# atomic host upgrade
# atomic host install postgresql vim postgresql-server
# systemctl reboot
db サーバーを web サーバーと同様に作成します。
web サーバーを踏み台として、dbサーバーに ssh 経由でログインしましょう。
その時に、ローカルホストから、秘密鍵を scp でコピーしておきます。
要すれば、web サーバーに ssh 経由でログインしてから、さらに、db サーバー
にログインする、ということになります。
db サーバーにログインできたら、次のコマンドを実行します。
# rpm -qa | grep postgresql
postgresql-10.6-1.fc29.x86_64
postgresql-libs-10.6-1.fc29.x86_64
postgresql-server-10.6-1.fc29.x86_64
# systemctl status postgresql.service
# systemctl enable postgresql.service
# systemctl start postgresql.service
# systemctl status postgresql.service
--------
Directory "/var/lib/pgsql/data" is missing or empty.
Use "/usr/bin/postgresql-setup --initdb"
--------
ということなので、以下のコマンドを実行します。
# /usr/bin/postgresql-setup --initdb
--------
* Initializing database in '/var/lib/pgsql/data'
* Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log
--------
# systemctl enable postgresql.service
# systemctl start postgresql.service
# systemctl status postgresql.service
立ち上がっていますよね。
# exit
$ exit
とすると、web サーバーに戻ります。
$ exit
で、ホストマシンに戻ります。
つづく。。
今回参考にしたサイトになります。
https://www.udemy.com/aws-14days/
つづく。
spectre_meltdown_checker をかけてみた（11/27最新版）
全て OK になっていました。
さあ、動くぞ！
AWS に ssh できなくなったのを直した
/etc/security/limits.conf を変に弄ってしまい、AWS のインスタンスに ssh 接続できなくなっていました。どうしたものか、と考えていたんですが、ハードディスクを外して、別のマシンに接続して、ファイルを編集する、という、 old-school なやり方が、案外、クラウドでもできそうなので、やってみて、成功したので、共有します。
「コピー」することによって、他のリージョンにデータを移行できます。
1.インスタンス1を停止します。
2.インスタンス1のスナップショット1を撮ります。
3.スナップショット1をコピーします（この時、sydney にコピーしました）。
鍵のペアがなければ、作成します。
4. sydney に移ります。
5. sydneyのスナップショット1からヴォリュームを作成します。
6. sydney にインスタンス2を作成します。
7. インスタンス2に、作成したヴォリュームを attach します。
8. マウントします（/dev/sdf1 になってました）。
9. 悪い所を修正します。
10. アンマウントします。
11. インスタンス2 を停止します。
12. インスタンス2 のスナップショット2を撮ります。
13. インスタンス2のスナップショット2をコピーします（この時、tokyo にコピーしました）。
14. tokyo に移ります。
15. スナップショット2から、ヴォリューム2 を作成（create volumn）します。
16. インスタンス1を停止しておきます。
17. インスタンス1 の root ヴォリュームを detach します。
18. ヴォリューム2 をインスタンス1 の、/dev/sda1 に attach します。
19. インスタンス1 をスタートします。
まあ、これでだめでも、新しいインスタンスを立ち上げて、従前のヴォリュームをattachしてマウントして、必要なものをコピーするだけでもいいです。
なんかおいしいもの食べたいなぁ。
sosreport-analyzer の開発状況
sosreport-analyzer の、0.0.2 を出しました。
date と、dmidecode のうち、bios と memory 情報の抜粋を標準出力に出すことを追加しました。
もちろん、sar-analyzer もついているので、そちらも楽しんでみてください。
sar-analyzer の開発を終了します
sar-analyzer の開発を終了し、sosreport-analyzer に引き継ぎます。
すでに sosreport-analyzer は存在していましたが、そちらで sar ファイルも解析できるようにしました。
では、sosreport-analyzer はどんなものになるかって？
私が感じたままになります。sosreport-analyzer の現在のバージョンは、0.0.1 となります。
お腹すいたなぁ。
libvirt の image 保存ディレクトリの変更
Fedora29 を使っていますが、デフォルトのマウント方法なので、/dev/mapper/fedora-root は / に、/dev/mapper/fedora-home が /home マウントされていて、それぞれ 49G と 1.1T の容量となっています。/var/lib/libvirt は、/ に入っているので、/var/lib/libvirt/images にイメージが増えていくと、あっという間に / の容量が一杯になってしまいます。
特に、preallocation=full などとすると、sparse 化できないため、これはいけません。
そこで、images ディレクトリだけ、/home に作成することにしました。
# mkdir /home/<user>/libvirt/images
# ln -sf /home/<user>/libvirt/images /var/lib/libvirt/images
# semanage fcontext -t virt_image_t -a "/home/<user>/libvirt/images"
# restorecon /home/<user>/libvirt/images
qemu ユーザーを、<user> グループに追加することも必要だったかな。
# usermod -a -G <user> qemu
# chmod 770 /home/<user>
お腹すいたなぁ。
sar-analyzer の開発状況（20181115）
sar-analyzer ですが、現在のバージョンは、10.22.2 となっています。
数日前に出した 10.22.1 では、sar_analyzer.c の多くの if clause が失敗していました。日本語環境であれば、sar_analyzer_jp.c を読むので、関係ないですけど。その問題を、今回のバージョンでは直しました。また、cswch のグラフが出ない問題も直しました。
常に最新のバージョンを使ってください。最新でないバージョンは、すべてが失敗バージョンとなりますので。
現在のバージョンは、10.22.2 ですよー。
お腹すいたァ。
sar-analyzer の開発状況（20181112-その2）
sar-analyzer ですが、現在のバージョンは、10.22.1 となっています。
今朝出した 10.22.0 には、ある環境下でグラフがうまく出力できない問題がありました。その問題を修正しています。
明日は大阪に遊びに行きまっせ！
sar-analyzer の開発状況（20181112）
sar-analyzer ですが、現在のバージョンは、v10.22.0 です。
今回のバージョンアップでは、コードのクリーニングを行いました。
これは、何度も行っています。c で書いているので、結構、自由に書けてしまいますが、見直してみると、後々問題となりそうな箇所がいくつも見つかったりします。
その、気付いたところについて、できるだけ直していく作業を、クリーニング、と呼んでいます。
また、実際にプログラム的に問題があったところも修正しています。
ともかく、いつも最新のバージョンを使うようにしてください。
次に、ちょっとした tips です。
デフォルトでは、CPU の数は、70 までとなっています。src/common.h に、
#define MAX_CORE_NUMBERS 70
としています。
これを、90 にすると、CPU が 90 まで記録されている sar ファイルを解析できるようになります。
このマクロは、src/common.h ファイルの、
/* ---------- macros ( tweak if needed ) ---------- */
というところにあります。
昨日は、松葉がにを食べましたよ。
sar-analyzer の開発状況（20181107）
sar-analyzer の、10.21.0 を出しました。
このバージョンでは、sar ファイルが 1分毎に書かれていても、グラフがきちんと表示できるようにしました。
また、日本語環境であれば、日本語の sar ファイルを正しく解析できるようになりました（していたつもりでしたが、ちゃんと出来ていなくて、ある方法でちょっと修正していたのをしなくてよくなりました）。
今日は、何を食べようかな。
Fedora29 にアップグレードしたら、ゲームマシンの X が立ち上がらなくなったので、対処した
Fedora29 にアップグレードしたら、ゲームマシンの X が立ち上がらなくなりました。
アップグレード直後の起動から、固まったようになってしまいました。
起動時に、e を押下して、起動するための行の最後に、 single を追加して、root パスワードを入力しました。
# systemctl set-default multi-user.target
# init 3
で、コンソールモードで立ち上がりました。
以下のコマンドを実行して、このゲーム端末には、VGA が2つある事がわかりました。
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)
/var/log/Xorg.0.log を確認すると、vesa を無効にすればよいと感じられました。
# vim /etc/modprobe.d/blacklist.conf
blacklist vesa
# shutdown -r now
ログインモードになります。
一般ユーザーでログインします。
$ export LANG=ja_JP.UTF-8
$ startx
GUI が立ち上がりました。
