2013年7月30日火曜日

Write failed: Broken pipeエラー

急にサーバーにsshで繋がらなくなった・・・(; ・`д・´)

サーバーが落ちたのかと思いサーバー会社に再起動の依頼を出そうかと思ったら
某氏が別のユーザーならログインできるとのことΣ(゚Д゚ υ) アリャ

以下、sshでログインできないアカウント名をuser1、
ログインできるアカウント名をuser2とする。
$ ssh user1@192.168.0.2
user1@192.168.0.2's password:
Write failed: Broken pipe
-vvオプションをつけて再度実行してみる。
$ ssh -vv user1@192.168.0.2
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /home/user1/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/user1/.ssh/identity type -1
debug1: identity file /home/user1/.ssh/id_rsa type -1
debug1: identity file /home/user1/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 126/256
debug2: bits set: 519/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.0.2' is known and matches the RSA host key.
debug1: Found key in /home/user1/.ssh/known_hosts:14
debug2: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user1/.ssh/identity ((nil))
debug2: key: /home/user1/.ssh/id_rsa ((nil))
debug2: key: /home/user1/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user1/.ssh/identity
debug1: Trying private key: /home/user1/.ssh/id_rsa
debug1: Trying private key: /home/user1/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
user1@192.168.0.2's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Write failed: Broken pipe
良く分からないエラー(´;ω;`)ウッ…
先ほどログインが出来るという別ユーザーでログインを確認してみる(; ・`д・´)
$ ssh admin@192.168.0.2
admin@192.168.0.2's password:
Last login: Tue Jul 23 19:43:23 2013 from 192.168.0.11
ログイン(゚∀゚)キタコレ!!

user2でログインできたのでuser1に切り替えてみようとすると、
エラーが発生してしまって切り替えが出来ないだとΣ(゚Д゚;エーッ!
$ su - user1
パスワード:
su: cannot set user id: リソースが一時的に利用できません
このエラーが解決できずに頭を悩ましていたら、
どこかのサイトを見たかなんかでふと、ファイルディスクリプタ数を確認してみることに。

これについては以前に記事も書いています。
ファイルディスクリプタ数について
$ ps -U user1 | wc -l
1026
1026・・・えーっと、確かデフォルトは1024だったような・・・?(; ・`д・´)
$ ulimit -n
1024
やっぱりド━━━━m9(゚∀゚)━━━━ン!!
なので、上限値をあげておきます。
$ ls -alt /etc/security/limits.d/
合計 12
drwxr-xr-x. 6 root root 4096  2月 25 09:56 2013 ..
drwxr-xr-x. 2 root root 4096  2月 25 09:56 2013 .
-rw-r--r--. 1 root root  152  4月 16 18:04 2012 90-nproc.conf
#アカウント名.confでファイル名を作る
$ sudo vi /etc/security/limits.d/user1.conf

#OSの最大値785338
* soft nofile 10000
* hard nofile 10000
とりあえず、ファイルディスクリプタ数の上限を越えてしまっているので、
再起動を行ってリセってを行い、ログインできなかったユーザーでログインをして、
設定したファイルディスクリプタ数が反映されているか確認する。
$ ulimit -n
10000
以上です(`・ω・´)ゞビシッ!!

これで直った気がしなくも無いけど、直っていないかもしれない((((;゚Д゚))))ガクガクブルブル
暫く様子を見るしか・・・orz

そもそも何でファイルディスクリプタ数の上限を越えるような状態になったのかは不明だったり・・・シーッ! d( ゚ε゚;)

参考URL

2013年7月9日火曜日

ドメインごとに実サーバーを振り分ける(複数ドメイン、パーチャルドメイン対応)

squidサーバーは一つで、キャッシュ対象となる実サーバーまたはドメインを複数利用したい場合についてになります。

現状は、squidサーバーが1台で、キャッシュ対象となる実サーバーA(192.168.0.1)に対してドメイン名test1.domain.comが割り当てられて運用しています。

そこに新しく実サーバーB(192.168.0.2)を追加しtest1.domain.comという名前を割り当て、
このドメインもsquidのキャッシュ対象としたい場合に、

squidサーバーにリクエストされたURLを見て、どっちの実サーバーに取りに行くか設定をしてあげる必要があります(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

squidサーバーへのリクエストが次の場合に、下記のように振り分ける。
test1.domain.comのリクエストは実サーバーA(192.168.0.1)に問い合わせる。
test2.domain.comのリクエストは実サーバーB(192.168.0.2)に問い合わせる。

この場合には、acl、cache_peer、cache_peer_accessなどのアクセスコントロールの設定が必要になります。

バーチャルドメインのリクエストを受け付けるために、
http_portにvhostオプションを設定します。
この設定が無いと、キャッシュが無かった場合にdefaultsiteで定義したドメインを利用して、
実サーバーへ問い合わせを行う?っぽいです。

なので、このvhostの設定をせずにアクセスコントロールしたとしても、
正しく振り分けられないので注意が必要です!
#プロキシーサーバーがクライアントからのリクエストを待ち受けるポート番号を指定。
http_port 80 accel defaultsite=test1.domain.com vhost
■手順1)aclの設定になります。
####################
#アクセスコントロールに関する設定
####################

#クライアントからのリクエストURLがtest1.domain.comだった場合に、
#エイリアス名を「domain_1」として定義する。
acl domain_1 dstdomain test1.domain.com

#クライアントからのリクエストURLがtest2.domain.comだった場合に、
#エイリアス名を「domain_2」として定義する。
acl domain_2 dstdomain test2.domain.com
サブドメイン全てを対象にした場合には、次のように記述する。
acl domain_1 dstdomain .domain.com
※エイリアス名は最大31文字までみたいです。 31文字を超えると次のようなエラーが発生していました。
2013/06/01 16:55:10| aclParseAclLine: ACL name '**************' too long. Max 31 characters allowed
■手順2)実サーバーの設定
####################
#実サーバーの設定
####################
#squidにキャッシュが無かった場合に、実サーバーの「test1.domain.com」に取りにいく。この設定を「server_web10」とする。
cache_peer squid.test1.domain.com parent 80 0 no-query originserver name=server_test1

#squidにキャッシュが無かった場合に、実サーバーの「test2.domain.com」に取りにいく。この設定を「server_web11」とする。
cache_peer squid.test2.domain.com parent 80 0 no-query originserver name=server_test2
実サーバー指定時にドメイン利用時の注意点として、
squidで受け付けるドメイン(cache_peerの実サーバーの指定)と、
実サーバーへの振り分け時のドメイン名(cache_peer_accessの指定がドメインだった場合)が同じだと正しく動作しないっぽいです。


たとえば、squidの受付ドメイン名が「test1.domain.com」で
「test1.domain.com」でsquidが受け取った後に、実サーバーへ転送する際の指定が
同じ「test1.domain.com」だとダメ。

普通に考えて、受け付けたドメインと転送先が同じだと
無限にループする的な感じがするできっとダメだと思います((((;゚Д゚))))ガクガクブルブル
というか、これが原因で恐らくサーバーが落ちた気がします(´;ω;`)ウッ…

なので、可能であればcache_peer_accessで指定する転送先の指定にはIPアドレスを使った方が良いかも?
ローカルIPでサーバーを指定するとか!1台のサーバーで複数個ドメインを設定したい場合には、
ポート番号で振り分けるとかすればいける気がします(゚д゚)(。_。)(゚д゚)(。_。) ウンウン

どうしても転送先の指定にもドメイン名でやりたい場合には、
squidからの参照用のドメイン名と、実際に使われるドメイン名を実サーバーに設定してあげて、
squidの設定では、cache_peerの実サーバーの指定時には参照用のドメインを使い、
cache_peer_accessの設定では、別々のドメインになるようにする。

■手順3)リクエストされたURLと実サーバーへの振り分け&許可設定
###################
#リクエストされたURLと実サーバーへの振り分け&許可設定
####################
#リクエストがaclで定義したdomain_1と一致した場合に、server_test1(192.168.0.1)への問い合わせを許可する。
cache_peer_access server_test1 allow domain_1

#リクエストがaclで定義したdomain_2と一致した場合に、server_test1(192.168.0.2)への問い合わせを許可する。
cache_peer_access server_test2 allow domain_2
次のような書き方も可能です。
#リクエストがaclで定義したdomain_1と一致しなかった場合に、server_test1(192.168.0.1)への問い合わせを許可する。
cache_peer_access server_test1 allow !domain_1
cache_peer_accessの定義はcache_peerに書かないといけない。 もし前に書いていると次のようなエラーが発生していました。
$ squid -k parse
2013/06/01 17:37:55| squid.conf, line 1231: No cache_peer 'server_test1'
2013/06/01 17:37:55| squid.conf, line 1234: No cache_peer 'server_test2'
以上で、アクセスコントロールの設定は完了になります。

後は、設定を反映させて完了ですド━━━━m9(゚∀゚)━━━━ン!!
#設定ファイルのチェック
squid -k parse

#設定の再読み込み
sudo /etc/init.d/squid reconfigure

or

#設定の再読み込み
squid -k reconfigure

アクセスコントロールの設定としては次のような記述が可能みたいです。
アクセスコントロールに関する設定
acl aclname acltype string1 ...
acl aclname acltype filename
aclname には任意の名前を指定できます。filename を指定する場合は、string1 の部分を指定したファイル内に 1 行ずつ記述します。

acltype に指定できる代表的なものとしては、以下のタイプが存在します。また、指定した acltype により、string1 へ記述する内容は異なります。

acl aclname src ipaddress/netmask ...
ipaddress/netmask で指定した送信元の IP アドレスに対して acl 名(aclname)を設定します。また、IP アドレスを -(ハイフン)で区切ることにより、IP アドレスの範囲を指定することも可能です。

acl aclname dst ipaddress/netmask ...
ipaddress/netmask で指定した送信先の IP アドレスに対して acl 名(aclname)を設定します。

acl aclname srcdomain domainname ...
送信元の IP アドレスの逆引きを行い,その結果のドメイン名(domainname)に対して acl 名(aclname)を設定します。

acl aclname dstdomain domainname ...
送信先のドメイン名(URL から得たドメイン名が domainname)に対して acl 名(aclname)を設定します。

acl aclname url_regex URL ...
URL で指定した URL に対して acl 名(aclname)を設定します。

acl aclname URL urlpath_regex URL ...
URL に指定した文字列を含む URL に対して acl 名(aclname)を設定します。

acl aclname time day-abbrevs h1:m1-h2:m2
曜日や時刻に対して acl 名(aclname)を設定します。day-addrevs には、S(日曜日)、M(月曜日)、T(火曜日)、W(水曜日)、H(木曜日)、F(金曜日)、A(土曜日)の指定が可能です。h1:m1-h2:m2 には時刻の指定をします。h1:m1 は必ず h2:m2 より前の時刻でなければなりません。

acl aclname port port ...
port で指定したポート番号に対して acl 名(aclname)を設定します。

acl aclname proto protocol ...
protocol で指定したプロトコル名に対して acl 名(aclname)を設定します。

acl aclname method HTTP_method ...
HTTP_method で指定した HTTP のメソッドに対して acl 名(aclname)を設定します。

acl aclname browser browser
browser で指定したブラウザ名に対して acl 名(aclname)を設定します。
以上です(`・ω・´)ゞビシッ!!

参考URL