【てん♪の成長絵日記】吉報：ブーシュカ継続のお知らせ

⇒しん♪さんのブーシュカを見る

ブーシュカ継続決定　との発表。
ユーザの声が届いたみたいですねぇ＾＾

法に訴えるレベルの活動もあったとかなかったとか。。。
賛否両論ありますが、私は素直に尊敬しますねぇ。
私は諦めて活動しない立場なので＾＾；


止むに止まれぬ事情でサービス停止に踏み切ったであろう運営さん、継続して大丈夫かぃ？（＾＾；；；；
改悪や、ユーザの期待を貶める内容にならないように祈っとりますよ（＾＾；；；；


それにしても、こういう騒動は、運営側も利用者側も、冷静になるのが大事ですよね。
騒ぎが大きくなると社会的な影響もあったり。。。

たとえばもし運営さんが倒産したら、ブーシュカもなくなるわけですが、、、
ゲームはゲームと割り切ることも必要なスキルかもしれないですよね。

私もブーシュカ停止には反対でしたが、
反対を訴える人たちのコメントも乱暴な物が目立ちましたね。。。
このような事象はサービス終了の度に少なからずありますが。。。

継続したらしたで、
バータウンのときは継続しなかったのに。。。とか。思う事もたくさんあると思いますけどね。

こういう前例を作ってしまってよかったのか、、、いやはや。
政治・経営は難しいです～。
私は絶対に関わり合いたくないですねぇ。

会員規約やゲームへユーザ登録する際の利用規約に、『同意した』ということを皆様、頭の片隅に留めておいてほしいと思いますね。

極端な話、糞の始末をしないのにペットを飼うな、的なテーマと共通する部分でもあるかもしれないですね。
マナーと規約は違うかもしれませんが。。。（ーωー；


まぁまぁWeb上の倫理・道徳については、私の思うところが多々あるので、
屁理屈をコネ始めるととまらなくなるので、この辺で終わります（＾w＾；；；


とりあえず、ブーシュカ継続、おめでとうございます！！

継続を訴え続けたみなさま、おつかれさまでした！！

備忘録：shとbashは違う！？ Tomcatの罠（w

Linux・・・特にCentOSを触っててハマったので・・・メモしておきますよ。


sh　と　bash　は挙動が違う・・・あたりまえですやんw


私も知ってたはずなんですが・・・。
ちょっと落とし穴がありました・・・。


昔はたしかに、shとbashは別物って知ってました。
でもですね。純粋なshは廃れ気味で・・・とかいう話を聞いた事ありまして。
「最近のは内部ではbash使ってるねん。」と聞いて、調べた事があるんですよ。

そしたら、
/bin/sh は /bin/bash へのシンボリックリンクでした。。。（＾＾；；；；

だ・か・ら・・・勘違いしてました。
挙動も同じだと・・・。


同じバイナリを起動してるんですが、、、shで呼び出したときと、bashで呼び出したときで、挙動が違います！！

もちろん、シェル起動後のインタラクティブコマンドの解釈ロジックとかは、同じメカニズムだと思います。

具体的に違う箇所は、実行時の環境変数とかですね。
私の環境（CentOS6.4）では、bashrc（/etc/bashrc、~/.bashrc 共に）や bash_profile が読み込まれてませんでした。
知人に相談したところ、POSIXがonになってたりoffになってたりとか、そういう違いもあるそうですね。


そりゃあ、いくら「.bashrc」に初期処理や環境変数を追記しても何も変わらないわけだわ・・・orz


普通に利用する上ではshを呼び出すことはなと思うので、問題になるケースは少ないかもしれませんね。
シェルスクリプトの先頭行を、「#!/bin/sh」とプログラムした場合は注意ですね～。


私がハマったのは、Tomcat6の起動スクリプト。
yumを利用してインストールした際に自動で作成される、サービス起動スクリプト。
/etc/rc.d/init.d/tomcat6

Tomcatのサービス起動・停止にはこのスクリプトを使っていました。


Tomcat起動時の、実行ユーザをtomcatとして運用したいのですが、
Tomcat上で動かすアプリ、このアプリは処理の途中で新規作成するのですが、そのファイルのパーミッションが「umask 022」状態になっています。

umask 002 で作って欲しいので、tomcatユーザのログイン時に起動しようと思って、
tomcatユーザの「.bashrc」や「.bash_profile」や「/etc/rc.d/init.d/tomcat6」内に
「umask 002」と記述しましたが・・・うまくいかなかったのです・・・。


原因は「/etc/rc.d/init.d/tomcat6」のTomcat起動にありました。
上記スクリプト内で、

su - tomcat -c "Tomcatのスタートアップコマンド"

という処理の記述がありました。


ふむ。suを利用して、rootユーザから実行してもtomcatユーザとしてTomcatを起動するようになっている。
・・・が、

実はこの記述、「su」ではなく「$SU」となっていた。
・・・なるほど、変数にコマンドのフルpathを入れてるんだな・・・。
・・・と思ったら、その先に落とし穴が。

「SU="su -s /bin/sh "」

・・・・・・おぉぅ。。。

「-s」オプションは推察するに、su実行後のシェルはこのシェルを使ってね、と指定するオプションに違いない。


記事前半で書いたことを知らなければ、完全にスルーしていたけれども・・・。


これ、bashにしたら解決？
みたいな。。。


スクリプト内に該当箇所は複数あるみたいだし・・・、
もしかして、bashrc内に設定済みの関係ない環境変数が、Tomcatの起動に悪影響を与えてしまったら嫌なので・・・、
TOMCAT_SCRIPTという変数を
前「/usr/xxx/xxx/Tomcatスタートアップコマンド」
　↓
後「umask 002; /usr/xxx/xxx/Tomcatスタートアップコマンド」

として、対処しますた。。。w；


suをsudoにしても良い気もするけれど、制限かけたり解除したりが面倒だったり。。。
試すのも面倒だったり・・・www；


Tomcat起動に環境変数を持ち込むには、
/bin/sh 実行時に読み込む環境変数のファイルへ書き込むか（そんなファイルがあるのか調べてないのでわかりませんがw）、、、あるいは・・・というか色々やりかたはありそう。
偉い人、スマートな方法教えてw

とにかく、Tomcat起動には /bin/bash ではなく /bin/sh が使われている可能性があることを、知っていても損はないと思いますよw

備忘録：SSH接続が遅いとき

ひさびさに技術系の記事をば。備忘録ですが。

過去、SSHサーバ接続で遅い時、という状況に何度も遭遇しているにも関わらず、色々忘れるのでメモ。
※SCPなど、内部でSSH通信を利用しているツールも遅くなります。


SSH接続が遅い、
という状況にはいくつかパターンがあります。

SSH接続は以下の手順で接続するとして、

１.コマンドを入力　「ssh -p ポート ユーザ@ホスト」など
↓・・・ケースA
２.パスワードを入力
↓・・・ケースB
３.接続完了。→SSHを利用した遠隔操作・・・ケースC

上記手順中のケースA～ケースCのどこが遅いかで原因が異なります。


まずケースA、
接続コマンド実行後、パスワードを求められるまでに時間がかかる、場合。
サーバ側のSSH設定を調整すると改善する場合があります。
（クライアント側が原因のときもありますが、考え方は同じで大丈夫だと思います）

詳細は ssh -v などのデバッグトレースモードにて途中経過を画面出力しつつ、
原因を探って下さい。

その中でよくある２点について、記録しておきます。
・DNSを利用したサーバ認証をしているが、タイムアウト
　ローカルネットワークにて、ipアドレスで直接通信している場合などに多いと思います
　→ ・sshd設定（例：/etc/ssh/sshd_conf）に、「UseDNS no」を追記
　　　※すでに「UseDNS yes」が記述されていれば、コメントアウトする（「#UseDNS yes」）　
　　・名前解決できるように、hostsファイル（/ets/hosts）やDNSに、接続先のIPを登録する
　　　※例えば、192.168.1.123 へ接続しようとしている場合、「192.168.1.123 dummy.com」などてきとうな名前をつけてしまえばOK

・GSSAPI認証を利用しているが、タイムアウト
　セキュリティ的に問題がなければ（ローカル環境や仮想環境なら問題ないと思われるが）、GSSAPI認証をOFFにすればよい
　→・sshd設定（例：/etc/ssh/sshd_conf）に、「GSSAPIAuthentication no」を追記
　　　※すでに「GSSAPIAuthentication yes」が記述されていれば、コメントアウトする（「#GSSAPIAuthentication yes」）

・・・思い出したのでもう１つ。
IPv6を無理矢理利用してて遅い事もあった気がします。
この場合、network設定でIPv6を利用しない設定（無効にする設定）にするか、
sshd設定にて「AddressFamily any」となっている所を「AddressFamily inet」とするとOKです。


Ubuntu12.04とかでサーバをつくると、SSHの初期設定で上記認証を利用する設定になっているみたいですね。


ケースB、
パスワード入力後、SSH接続の確立までが遅い場合。
・・・なんか経験はある気がするのですが、、、忘れましたw＾＾；；；；；；

思い出したら追記しますorz


ケースC、
接続後の遠隔操作にて、レスポンスやコマンドの送信が遅い場合、全体的に遅い場合が多く、ネットワーク全体の通信環境（速度、遅延時間）が悪い場合が多いです。
ネットワーク管理者に相談、といった所ですね。
pingやnmapなどの通信応答チェックでネットワークを調査してくださいませ。


以上でっす。

クライアント側のSSH_confでも、GSSAPI認証の設定などあるかもしれません。
もしサーバ側を調整しても改善しなければ、クライアントも調整してみてくださいませ。