DKIM設定してさらにメール到達率を上げる

どうも、俺です。

男もすなるDKIMといふものを女もししてみむとてするなり。

環境はCentOS7.2 + Postfix 2.10.1 です。

OpenDKIMのインストール

yumで入れます。

# yum install opendkim

鍵やら何やらを作るので、専用のディレクトリを作成します。

# mkdir /etc/opendkim/keys/MYDOMAIN.com(ドメイン名)

で、鍵やら何やらを作ります。

# opendkim-genkey -D /etc/opendkim/keys/MYDOMAIN.com/ -b 1024 -d MYDOMAIN.com -s koexuka

-Dは生成ディレクトリ
-bは1024や2048など鍵のビット長
-dはドメイン名
-sはセクレタ名。鍵を識別できる分かりやすい名前が良いです。サイト名や作成日付など。

これでファイルが2つできてるはずです。

# ls -l /etc/opendkim/keys/MYDOMAIN.com

-rw------- 1 opendkim opendkim 887  3月 22 15:11 koexuka.private
-rw------- 1 opendkim opendkim 317  3月 22 15:11 koexuka.txt

設定ファイルの更新

KeyTableファイルを編集します。

# vim /etc/opendkim/KeyTable

koexuka._domainkey.MYDOMAIN.com MYDOMAIN.com:koexuka:/etc/opendkim/keys/MYDOMAIN.com/koexuka.private

SigningTableファイルを編集します。

# vim /etc/opendkim/SigningTable

*@MYDOMAIN.com koexuka._domainkey.MYDOMAIN.com

TrustedHostファイルを編集します。

# vim /etc/opendkim/TrustedHosts

127.0.0.1
::1
#host.example.com
#192.168.1.0/24

CIDR形式で記述できます。
上記IPにマッチした場合だけ署名されます。

opendkim.confを編集します。

# vim /etc/opendkim.conf

Mode sv
#KeyFile        /etc/opendkim/keys/default.private #コメントアウトする
KeyTable       /etc/opendkim/KeyTable
SigningTable   refile:/etc/opendkim/SigningTable
ExternalIgnoreList     refile:/etc/opendkim/TrustedHosts
InternalHosts  refile:/etc/opendkim/TrustedHosts

/etc/sysconfig/opendkimファイルを編集します。

# vim /etc/sysconfig/opendkim

# これを追加
AUTOCREATE_DKIM_KEYS=NO

main.cfを編集します。

#vim /etc/postfix/main.cf

# これを追加
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

Postfixを再起動します。

# systemctl restart postfix

ドメイン情報を更新

利用しているDNSサーバーでTXTゾーンにDKIMの内容を反映させます。
まず、公開鍵の内容を確認します。

# cat /etc/opendkim/keys/MYDOMAIN.com/koexuka.txt

koexuka._domainkey     IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNAD(〜略〜)//ciSVp9o(〜略〜)ZBCwIDAQAB" )  ; ----- DKIM key koexuka for MYDOMAIN.com

DNS管理画面で以下を追加します。

Aレコード koexuka._domainkey.MYDOMAIN.com 123.45.67.89(IPアドレス)
TXTレコード koexuka._domainkey p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNAD....ZBCwIDAQAB; v=DKIM1; k=rsa;

あとは実際にメールを送信してみて、受信側でメールヘッダに
dkim=pass
とあればOKです！

以上でぇぇぇぇえぇ〜す。

PostgreSQL10のでパーティショニング

どうも、俺です。

PostgreSQLがv10になってからパーティショニングの設定が超ラクになりました。
これまでは、CREATE TABLE するときにトリガーや関数を逐一設定する必要がありましたが、
PostgreSQL 10からはCREATE TABLE文の中だけでパーティショニングの設定が可能です。

簡単なサンプルで見てみます。

-- 元となる親テーブルの作成
CREATE TABLE test_table (
  id SERIAL,
  user_id INTEGER NOT NULL,
  name VARCHAR(512) NOT NULL,
  created_at TIMESTAMP NOT NULL
)
-- user_idをキーにパーティションする
PARTITION BY LIST (user_id);

-- user_idが1の場合はtest_table_1へ
CREATE TABLE test_table_1 PARTITION OF test_table FOR VALUES IN (1);
-- user_idが2の場合はtest_table_2へ
CREATE TABLE test_table_2 PARTITION OF test_table FOR VALUES IN (2);
-- user_idが3と4の場合はtest_table_3へ
CREATE TABLE test_table_3 PARTITION OF test_table FOR VALUES IN (3,4);
-- user_idが5と6と7の場合はtest_table_4へ
CREATE TABLE test_table_4 PARTITION OF test_table FOR VALUES IN (5,6,7);
.
.
.

これだけでOKです。


ただ、このパーティショニングの方法だと、user_idが増えれば増えるほどパーティショニング子テーブルをいちいち CREATE TABLE する必要があるので、
子テーブルを予め10個作成しておき、user_idを10で割った余りを元にパーティショニングするように変更してみます。

CREATE TABLE test_table (
  id SERIAL,
  user_id INTEGER NOT NULL,
  name VARCHAR(512) NOT NULL,
  created_at TIMESTAMP NOT NULL
)
-- user_idを10で割った余りをキーにパーティションする
PARTITION BY LIST ((user_id%10));

CREATE TABLE test_table_1 PARTITION OF test_table FOR VALUES IN (1);
CREATE TABLE test_table_2 PARTITION OF test_table FOR VALUES IN (2);
CREATE TABLE test_table_3 PARTITION OF test_table FOR VALUES IN (3);
CREATE TABLE test_table_4 PARTITION OF test_table FOR VALUES IN (4);
CREATE TABLE test_table_5 PARTITION OF test_table FOR VALUES IN (5);
CREATE TABLE test_table_6 PARTITION OF test_table FOR VALUES IN (6);
CREATE TABLE test_table_7 PARTITION OF test_table FOR VALUES IN (7);
CREATE TABLE test_table_8 PARTITION OF test_table FOR VALUES IN (8);
CREATE TABLE test_table_9 PARTITION OF test_table FOR VALUES IN (9);
CREATE TABLE test_table_0 PARTITION OF test_table FOR VALUES IN (0);

以上でぇぇぇえ〜す。

SQLiteのコマンドラインを見やすくしちゃう

どうも、俺です。

SQLiteのコマンドラインって見にくいですよね。
そこで見やすくする方法についてメモ。

$ vim ~/.sqliterc

.header on
.mode column

これでOKです。


または、SQLiteのコマンドライン内で直接、

$ sqlite3 hoge.sqlite

sqlite> .header on
sqlite> .mode column

これでもOKです。


以上でぇぇぇす。

今さらながら、Let's EncryptでSSL対応 + 自動更新

どうも、俺です。

今日は、随分前からWeb界隈でもてはやされているLet's Encryptの導入と自動更新設定についてメモ。

環境はCentOS6.9。たぶんCentOS7系でも一緒だと思う..。
Apache 2.4。

(1) certbotをダウンロード

$ wget "https://dl.eff.org/certbot-auto"

// certbot-autoを適当なPATHへ持っていく
# mv certbot-auto /usr/local/bin

// certbot-autoに実行権限を付与
# chmod +x /usr/local/bin/certbot-auto

(2) SSL証明書を作成

※注意 :この時点で対象サーバーにドメインが当たっていないと以下のコマンドは失敗します。

# certbot-auto certonly --webroot -w /www/path/to/public -d example.com --email info@example.com

うまくいくと

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-07-18. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

が表示されます。

(3) 証明書の確認

$ ls /etc/letsencrypt/live/example.com

README  cert.pem  chain.pem  fullchain.pem  privkey.pem

• cert.pem ... 証明書
• chain.pem ... 中間証明書
• fullchain.pem ... 証明書と中間証明書とを一緒にした証明書
• privkey.pem ... 秘密鍵

(4) Apache(2.4系)の設定

対象の.confファイル内に以下を記述。

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

※2.2系の場合は以下も記述。

SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

(5) Apache再起動

# /usr/local/apache2/bin/apachectl restart

(6) Let's Encrypt 自動更新設定

Let's Encryptの証明書は3ヶ月で有効期限が切れます。
そのためcronで自動更新させましょう。

# vim /etc/crontab

30  5  *  *  1  root /usr/bin/certbot-auto renew -q --no-self-upgrade --post-hook "/usr/local/apache2/bin/apachectl restart"

↑毎週月曜AM5:30に更新コマンドを叩いています。
更新ができるようになる30日前になったら、証明書が更新されます。
-qオプション ... 出力なし。
--no-self-upgrade ... プログラムの新バージョンへの自動更新をしない。




以上でぇぇぇえぇぇす。

"〜〜" not found using pkg-configのエラーが出る

どうも俺です。

Linux上で何かのプログラムをインストールしようとして、

$ ./configure
ERROR: libwebp >= 0.2.0 not found using pkg-config

のようなエラーが出る場合、pkg-configとやらが悪さをしている可能性があります。

その場合は、

$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

で解消する場合があるのでお試しあれ。
以上でぇぇえぇぇぇす。

php: error while loading shared libraries: libpq.so.5: cannot open shared object fileが出る

どうも俺です。

構築したばかりのサーバーで

$ php -v

と打ってphpのバージョンを確認しようとしたら、

php: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory

というエラーが出ちゃいました。

エラー内容のとおり、
何かしらの共有ライブラリ(今回はlibpq.so.5)が読み込めないというエラーです。

ちなみにrootになって同じコマンドを打つと

# php -v
PHP 5.6.24 (cli) (built: Mar  2 2017 15:32:45) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

と問題なく実行されます。
つまり、今回のエラーは何かしらのPermissionが関係してるだろうと予想つきました。

こういう場合は共有ライブラリの依存関係を確認してみます。

$ ldd /usr/local/bin/php
        linux-vdso.so.1 =>  (0x00007ffda23d7000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2982411000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f29821fa000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2981fe0000)
        libpq.so.5 => not found
        librt.so.1 => /lib64/librt.so.1 (0x00007f2981dd7000)
        libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f2981b6e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f298186c000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f2981667000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f298144e000)
        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f29810e4000)

注目すべきは、libpq.so.5 => not found となっているところです。


今度はrootになって確認してみます。

# ldd /usr/local/bin/php
        linux-vdso.so.1 =>  (0x00007ffce4d60000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f0d05ff1000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f0d05dda000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0d05bc0000)
        libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x00007f0d05997000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f0d0578e000)
        libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f0d05525000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0d05223000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0d0501e000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f0d04e05000)

今度は libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 と表示されました。

ということで/usr/local/pgsqlディレクトリを確認してみます。

$ ls -l /usr/local
drwxr-xr-x   7 root     root       62  3月  2 15:44 bin
drwxr-xr-x.  2 root     root       22  7月 29  2016 etc
drwxr-xr-x.  2 root     root        6  8月 12  2015 games
drwxr-xr-x.  3 root     root       16  7月 29  2016 include
drwxr-xr-x.  3 root     root       30 12月  6 15:26 lib
drwxr-xr-x.  2 root     root        6  8月 12  2015 lib64
drwxr-xr-x.  2 root     root        6  8月 12  2015 libexec
drwx------   6 postgres postgres   52  3月  2 14:41 pgsql
drwxr-xr-x   3 root     root       16  3月  2 15:33 sbin

予想通りpgsqlユーザーのみ読み書きできる状態になってしまっていました。

適切に権限を追加して完了。




以上でぇぇぇぇす。

公開鍵認証を使い、sshで2段階ログイン(多段ログインもできちゃう)

どうも、俺です。

今日は、

~/.ssh/config

を使って、2段階先のサーバーへsshログインする方法をメモ。

＜クライアント＞ → ＜サーバーA(192.168.0.2)＞ → ＜サーバーB(192.168.0.3)＞
のように接続する際に

$ ssh サーバーB

と打てばサーバーBへsshログインできます。

(1) .ssh/configを編集

$ vim ~/.ssh/config

Host ＜サーバーA＞
  HostName 192.168.0.2
  User ユーザー名
  Port 22
  IdentifyFile ~/.ssh/serverA_id_rsa

Host ＜サーバーB＞
  HostName 192.168.0.3
  User ユーザー名
  Port 22
  ProxyCommand ssh -W %h:%p ＜サーバーA＞
  IdentifyFile ~/.ssh/serverB_id_rsa

※クライアント側のPCにはサーバーAとサーバーBの認証鍵
~/.ssh/serverA_id_rsa
~/.ssh/serverB_id_rsa
があることが前提です。

(2) ログインする

$ ssh サーバーB

複数先のサーバーへログインする場合は、
上記の.ssh/config内に踏み台にするサーバーをドンドン追記していけばOKです。


以上でぇぇぇえぇぇす。

tmuxですべてのペインに同じコマンドを同時入力！

どうも、俺です。

タイトルの通り、tmuxで複数のペイン分割した状態で
全てのペインに同じコマンドを送ってやりたいとき。

: set-window-option synchronize-panes on

これです！


ちなみにやめたい時は

: set-window-option synchronize-panes off

です。

複数のペイン上で複数の作業を同時進行したい時、
とかに使えます。

以上でぇぇぇぇす！

vimでファイルを開いている最中にdiffを見る

どうも、俺です。

2つのファイルにある差分をチェックする場合、

$ diff aaa.txt bbb.txt

またはvimをつかって

$ vimdiff aaa.txt bbb.txt

とやることが多いです。

今回は、vimでファイルを開いてしまった状態からdiff(vimdiff)を見る方法について。
とあるファイルをvimで開いてから、

:vsp ファイル名

または

:sp ファイル名

で、分割表示している状態で、

:windo diffthis

と打てばdiffを確認できます！

ちなみに、

:windo

は、vimで分割しているすべての画面に同じコマンドを打つ時に使えます。


以上でぇぇぇぇす！

.gitignoreが反映されない場合

どうも、俺です。

.gitignoreに除外ファイル/ディレクトリを追記しても反映されない場合の対応方法についてめもめも。

1) キャッシュが効いてしまっているので削除します。

$ git rm --cached /path/to/directory (or file)

2) コミットします。

$ git add .gitignore
$ git add /path/to/directory (or file)
$ git commit -m "COMMIT MESSAGE"

以上でぇぇぇぇぇぇす。

※参照 .gitignore に設定を追加して反映させる: Qiita

PostgreSQLでスキーマ(テーブル定義)を取得する方法

どうも、俺です。

 PostgreSQLでターミナル上からスキーマ情報を取得したい場合。

$ pg_dump --schema-only DATABASE_NAME > schema.sql

以上でぇぇぇぇす。

Apache(2.4系)のソースインストールで "checking for OpenSSL version >= 0.9.8a... FAILED"が出る

どうも、俺です。

Apacheをソースインストールするときにつまづいたのでメモ。
./configureした際に

checking for OpenSSL version >= 0.9.8a... FAILED
configure: WARNING: OpenSSL version is too old
no
checking whether to enable mod_ssl... configure: error: mod_ssl has been requested but can not be built due to prerequisite failures

が出ちゃった場合。

# yum install openssl-devel

で解決！

※僕の場合、CentOS6.7 Apache 2.4.12でした。

以上でぇぇぇぇす。

PostgreSQLのロック確認方法

どうも、俺です。

PostgreSQLで発生しているロックの確認の方法です。

PostgreSQL：ロックの確認と解除方法

上記にありますが、

SELECT l.pid, db.datname, c.relname, l.locktype, l.mode
FROM pg_locks l
        LEFT JOIN pg_class c ON l.relation=c.relfilenode
        LEFT JOIN pg_database db ON l.database = db.oid
  WHERE datname='{DATABASE_NAME}'
ORDER BY l.pid;

です。

9.6. ロックとテーブル
にあるように、クエリ実行中は数種類のロックがかかっています。

実際に測ってみると、
SELECT文でも AccessShareLockがかかりますが、
これはAccessExclusiveLockモードとのみ競合するとのことなので、
ALTER TALBE, DROP TABLE, VACUUM FULL, LOCK TABLE
以外のクエリに対しては何ら問題ありません。


以上でぇぇぇぇす。

PostgreSQLのキャッシュヒット率計算

どうも、俺です。

PostgreSQLのキャッシュヒット率の計算をググって出てきたのでメモ。

以下のサイトに書いてありました。
稼動統計情報を活用しよう(2)

・テーブルへのキャッシュヒット率の計算

SELECT relname,
   round(heap_blks_hit*100/(heap_blks_hit+heap_blks_read), 2)
   AS cache_hit_ratio FROM pg_statio_user_tables
     WHERE heap_blks_read > 0 ORDER BY cache_hit_ratio;

・インデックスのキャッシュヒット率の計算

SELECT relname, indexrelname,
   round(idx_blks_hit*100/(idx_blks_hit+idx_blks_read), 2)
   AS cache_hit_ratio FROM pg_statio_user_indexes
     WHERE idx_blks_read > 0 ORDER BY cache_hit_ratio;

以上でぇぇぇぇす。


※2015.6.25 追記

postgresql_トラブルシュート
を参考にテーブルキャッシュヒット率とインデックスヒット率を同時に計算できるんじゃないかと考えました。
利用するテーブルはpg_statio_user_tablesです。

SELECT *,
(heap_blks_hit*100) / (heap_blks_read+heap_blks_hit) AS disk_ratio,
(idx_blks_hit*100) / (idx_blks_read+idx_blks_hit) AS idx_ratio
FROM pg_statio_user_tables
WHERE heap_blks_hit >= 1
and schemaname = 'public' ORDER BY idx_ratio;

統計情報を持つテーブルについてはこちら(統計情報コレクタ)を参考に。

ただ、なぜかこのクエリだといくつかのインデックスヒット率は、上述したクエリで算出したものと異なる場合がある。。
なので、修正しないといけない...。


※2015.6.26 追記
キャッシュヒット率の合計平均を出すクエリを作りました。

・テーブルへのキャッシュヒット率平均

SELECT avg (cache_hit_ratio)
FROM
(SELECT relname,
   round(heap_blks_hit*100/(heap_blks_hit+heap_blks_read), 2) AS cache_hit_ratio 
FROM pg_statio_user_tables
     WHERE heap_blks_read > 0) AS foo;

・インデックスヒット率の平均

SELECT avg(cache_hit_ratio)
FROM
(SELECT relname, indexrelname,
   round(idx_blks_hit*100/(idx_blks_hit+idx_blks_read), 2) AS cache_hit_ratio 
FROM pg_statio_user_indexes
WHERE idx_blks_read > 0) AS foo;

統計情報をリセットする場合は

SELECT pg_stat_reset();

を叩けばリセットされます。

設定を変更して統計を取り直したい場合などに使います。

sshで "Received disconnect from xxx.xxx.xxx.xxx: 2: Too many authentication failures for" でログインできひん

どうも、俺＠仕事中です。

sshでログインしようとして

$ ssh username@xxx.xxx.xxx.xxx
Received disconnect from xxx.xxx.xxx.xxx: 2: Too many authentication failures for username

が出てログイン出来ないとき。

$ ssh username@xxx.xxx.xxx.xxx -o PreferredAuthentications=password

とやればとりあえずログイン出来る、と思います。
※パスワードログインする場合

このエラーは、サーバ側のsshd_configにある

MaxAuthTries 6

の回数を超えてしまったために出るエラーです。
なので、サーバ側でこの値を増やしてsshd再起動すれば解決しますが、
無闇に増やすのはセキュリティ上多少心配です。

sshの公開鍵認証を設定していると、
数種類のサーバ向けに秘密鍵を用意する事が多いと思いますが、
そういう場合、sshが順番に鍵を使って認証していき（もちろんパスワード認証も）
その結果MaxAuthTriesを超えてしまう、
という事があるようです。
なので不要な秘密鍵を消すために、

$ ssh-add -D

を行ってから接続するのも別の解決策です。

どういう認証手順を踏んでるか確認するには、

$ ssh username@xxx.xxx.xxx.xxx -vvv

と 打てば詳細なログを出力できます。



以上でぇぇぇぇぇす。

Linuxでユーザをグループに追加する

どうも、俺＠腹減ったです。

Linuxを作成したユーザを別のグループに追加したいとき。

$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka)

今はkoexukaユーザはgid=500のkoexukaグループに属している状態です。
追加してwheelグループに追加しちゃいましょう。

# gpasswd -a koexuka wheel
$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka),10(wheel)

見事wheelグループに追加されました。
では、やっぱwheelグループから削除したいとき、

# gpasswd -d koexuka wheel
$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka)

はい、見事にwheelグループから脱却できました。

ちなみにusermodコマンドでもグループ追加できます。
同じようにkoexukaユーザをwheelグループに追加したいときは、

# usermod -G wheel koexuka
$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka),10(wheel)

のように出来ます、が！

usermodコマンドでグループに追加すると、
すでに他のグループが設定されていた場合は危険です。

$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka),10(wheel)
// ↑↑グループはkoexukaとwheel

# usermod -G hogegroup koexuka
$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka),502(hogegroup)

// ↑↑設定されていたwheelが消える！！

上記のようにコマンドを叩くと、すでに設定されたグループが削除されてしまいます。
なので、

# usermod -G hogegroup, wheel koexuka
$ id koexuka
uid=500(koexuka) gid=500(koexuka) groups=500(koexuka),502(hogegroup),10(wheel)

のように、属するグループを,（カンマ）ですべて指定しなければいけません。

面倒なので、つまりgpasswdコマンドを使いましょう！
という結論。


以上でぇぇえぇぇぇす。

Linuxカーネルが32bitか64bitか、またCPUが64bit対応か32bit対応かを確認する

どうも、俺＠帰る前です。

L7ロードバランサHaproxyを使う（その１ インストールまで）を書いてて、調べる機会があったのでまとめておきます。

・Linuxが32bitカーネルか64bitカーネルかを調べる

uname -a
Linux centos 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

のように、x84_64が出てくると64bitカーネルです。
32bitカーネルの場合は

uname -a
Linux centos 2.6.18.8-xenU #4 SMP Fri Sep 26 11:41:46 JST 2008 i686 unknown

のように、i686やi386が出ます。


・CPUが32bitアーキテクチャか64bitアーキテクチャかを調べる

cat /proc/cpuinfo | grep lm
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up pni vmx cx16 popcnt lahf_lm

のように、flagsに「lm」が出てくれば64bitアーキテクチャ。
ちなみにlmは「ロングモード(x86_64)」の略のようです。
32bitのCPUでは「lm」が出てきません。

※参考「/proc/cpuinfo 再調査編 - ぴろにっき」


以上でぇぇぇぇぇえす。

L7ロードバランサHaproxyを使う（その１ インストールまで）

どうも、俺＠仕事中です。

今日はオープンソースのロードバランサの1つの「Haproxy」について紹介します。
L7なのでアプリケーション層レベルでのロードバランシングが可能です。
※httpのURLパラメータを見てアクセスするサーバを振り分ける、など可能です。
※もちろんL4で稼働させることも可能です。

開発環境はCentOS5.6(64bit)です。

2013.10.21時点での安定版の最新はv1.4.24です。
上記のURLからtarballを落としてからインストールします。

tar zxvf haproxy-1.4.24.tar.gz
cd haproxy-1.4.24
make TARGET=linux26 ARCH=x86_64
sudo make install
# make時のフラグは同梱されているREADMEに書いているので、参考に！

これでデフォルトの/usr/local以下にインストールされます。
インストール先などのオプションを指定するには、同梱されているMakefileを変更すればOKです。

次に起動スクリプトを/etc/init.d以下へ

cp examples/haproxy.init /etc/init.d/haproxy
chmod +x /etc/init.d/haproxy

こうしておくことで

/sbin/service haproxy start

で起動したり出来ます。

つぎに設定ファイルです。

mkdir /etc/haproxy
cp examples/example.cfg /etc/haproxy/haproxy.cfg

すでにひな形があるので、それを元に設定できます。
設定については細かいオプションも用意されており、柔軟に設定可能です。

ちょっと長くなりそうなので、近いうちに"その２"書きます。

以上でぇぇぇぇぇえす。


※2013.11.07追記
L7ロードバランサHaproxyを使う（その２ 設定から起動）書きました。

sftpで鍵認証する際のオプション

どうも、俺＠仕事中です。

 いつも忘れるのでめもめも。 sftpコマンドを使ってサーバ接続する際に、公開鍵認証にしているときに鍵ファイルを指定する方法。

sftp -oIdentityFile=/path/to/鍵ファイル username@example.jp

オプションの -oIdentityFile= は username@example.jp の前に書かないとアカンで！


以上でぇえっぇえぇっぇえぇす。

tcpdumpじゃないtcpセッションツールmiruoが凄すぎた

どうも、俺＠家です。 

最近、ネットワーク関連の調査でtcpについて調べたり、tcpdumpを使って通信のやり取りを見まくっていました。
 ネットワークについてボトルネックを調べるときは、Linuxサーバのカーネルの設定を見なおしたり、tcpdumpでtcpセッションの内容を確認したりします。
ググればたくさん出てきますが、ネットワーク関連については割と新しめのポストで
Linux Books Support Siteなどが参考になりした。

ところでtcpdumpですが、当然ながらとても便利です。
オプションも豊富で自分の知りたい情報を知ることができます。
ただし、大量アクセスのあるサイトで使うとあらゆるオプションを駆使してフィルタリングしても、ログが大量に出力されて解析が大変ですね。

「どこかの天才がもっとシンプルにTCPセッションを見れるツール作ってないかなぁ」と思っていたら、いました天才が。
高負荷サイトのボトルネックを見つけるには
しかも日本人、しかも2年も前。KLabの開発すげー。
miruoというツールです。

早速インストールしましょう。
※CentOS 6.2

git clone https://github.com/KLab/miruo.git
cd miruo
./configure
make
〜略〜
make[1]: *** [miruo.o] エラー 1
make[1]: ディレクトリ `/usr/local/src/miruo' から出ます
make: *** [all] エラー 2

ありゃ、エラーが出た。

makeのログをたどってみると、

miruo.h:24:17: error: pcap.h: そのようなファイルやディレクトリはありません

きっとpcapらしきライブラリが足りないみたい。

yum install libpcap-devel

よし、インストールを続けよう。

make
make install
make[1]: ディレクトリ `/usr/local/src/miruo' に入ります
test -z "/usr/local/sbin" || /bin/mkdir -p "/usr/local/sbin"
  /usr/bin/install -c miruo '/usr/local/sbin'
make[1]: `install-data-am' に対して行うべき事はありません.
make[1]: ディレクトリ `/usr/local/src/miruo' から出ます

これで/usr/local/sbin/miruoがインストール完了です！
〜に対して行うべき事はありません、と注意されますが、
心のなかで「そうなんですね」と返事しておきましょう。

このmiruoですが、「怪しいTCP通信」だけをピックアップして表示してくれるツールです。
なのでtcpdumpのように全TCPパケットを表示することもないので、解析がしやすくなります。
例えば

1392             0.343 |   (Client IP):50861 == (My Server IP):80    | Total 3 segments, 126 bytes
1392:0000 19:27:28.800 |          SYN_SENT >----S-> SYN_RECV          | 9098F675/00000000   78 - <mss=1410, wscale=4, timestamp 560465119 0, sackOK>
1392:0001 19:27:28.801 |       ESTABLISHED <-a--s- -="" 1392:0002="" 19:27:29.144="" 2e7570d5="" 66="" closed="" lt="" mss="1460," sackok="" syn_recv="" wscale="7>">---R--> CLOSED            | 9098F676/00000000   60 - <>

の場合だと、
１）クライアント→SYN→サーバ
２）サーバ→SYN+ACK→クライアント
３）クライアント→RST（強制終了）
のようなやり取りが行われていたり、

1431             0.345 |   (Client IP):48646 == (My Server IP):80    | Total 13 segments, 2185 bytes
1431:0000 19:27:28.824 |          SYN_SENT >----S-> SYN_RECV          | 6F591A36/00000000   74 - <mss=1420, sackOK, timestamp 14126836 0, wscale=5>
1431:0001 19:27:28.824 |       ESTABLISHED <-a--s- -="" 1431:0002="" 19:27:28.830="" 66="" b1fea867="" established="" lt="" mss="1460," sackok="" syn_recv="" wscale="7>">----S-> SYN_RECV          | 6F591A36/00000000   74 - <mss=1420, sackOK, timestamp 14126936 0, wscale=5>
1431:0003 19:27:28.830 |       ESTABLISHED <-a--s- -="" 1431:0004="" 19:27:28.903="" 66="" b1fea867="" established="" lt="" mss="1460," sackok="" syn_recv="" wscale="7>">-A----> ESTABLISHED       | 6F591A37/B1FEA868   60 - <>
1431:****              |                                              |
1431:0010 19:27:29.074 |         FIN_WAIT1 >-A---F> ESTABLISHED       | 6F591B62/B1FEACEE   60 - <>
1431:0011 19:27:29.074 |         FIN_WAIT2 <-a---f -="" 1431:0012="" 19:27:29.169="" 54="" b1feacee="" gt="" last_ack="" lt="" time_wait="">-A----> CLOSED            | 6F591B63/B1FEACEF   60 - <>

の場合は
１）クライアント→SYN→サーバ
２）サーバ→SYN+ACK→クライアント
３）クライアント→SYN　（またSYNかよっ！
４）サーバ→SYN+ACK→クライアント　（ほらよっ、二度目やで！
５）クライアント→ACK　（やっと接続
のようなやり取りが行われていたり、一目瞭然です。

/usr/local/sbin/miruo --live

と打てば通常のtcpdumpコマンドと同等の結果を得ることも出来ます。
※ポートやホストの指定はできますが、tcpdump独自のオプション（-xや-v、-nなど）は使えませんので、
それらを使いたい場合はtcpdumpを使いましょう。

サーバ側のネットワーク関連のカーネルパラメータのチューニング不足や、クライアントからの不自然なパケット（または攻撃）などを捉える事が用意に出来ます。

SYN再送を補足するかどうか、RSTフラグのパケットを補足するかどうか、到達に◯ミリ秒以上かかった通信を補足するかどうか、などいくつか使えそうなオプションも用意されているので用途に合わせてオプション駆使することも可能です。
超便利。


以上でぇぇぇぇす。