2013 08,02 19:01 |
|
本日上がってきたサーバ証明5本
そのうちX509_check_private_key:key values mismatchとエラーがあったのは、4本 おい! どれでもドメインでつけられたファイル名と、中身がちぐはぐ・・・おいっ!しっかりしろよ! 証明書の内容を見る方法は - openssl x509 -noout -text -in filename.crt 秘密鍵の内容を見る方法は - openssl rsa -noout -text -in filename.key で確認しました 最初は、パスフレーズを間違えたか!?って焦ったけど、秘密鍵の確認で、パスを求めれるので 設定したパスを入力したちゃんと表示されたから、パスフレーズが間違っているということはなかった で、なにがちぐはぐしていたかというと、コモンネームがファイル名のドメインと違う ある意味、トラップです。。。 PR |
|
2013 07,29 19:42 |
|
Android でandroid.os.NetworkOnMainThreadException が出て起動しないという現象
調べた見たら、 Andorid3.0以降から、メインクラスから、ネットワーク処理を許していないとのこと で、軽く嵌った1段として、「メインクラス」 メインクラスではなくて、本当はメインスレッドからのネットワーク処理を許していないということ サブクラスを作り、そこに処理を書いてもメインスレッドからコールしても意味がない! で、その対応策として、AsyncTask を使用する 非同期でネットワーク処理を行うように、処理を記述 試してみたら、ほんとに非同期・・・UI部分を引っ張ってくるには便利なクラスだと思う だけど、1回目のネットワーク処理の結果を使い、2回目のネットワーク処理をする自分のアプリでは無意味。。。orz だって、非同期なんだもん。。。1回目の結果を待たずに2回目が実行されてしまう そんなわけで、自作のクラスを作り、メインスレッドからサブスレッドを実行。 サブスレッドにはネットワーク処理を行い、それが終わるまでメインは待機という JAVAスレッドの基本で対応 なんだよ、ほんとに。。。Androidはいろいろ嵌る はぁ、めんどくせい こんなもんがほんとに儲かるのか?って、いまだに半信半疑な人なのでした |
|
2013 07,29 19:34 |
|
ログを見ながらテストをしていたら、気になるログが現れたので、
テストを一時中断して、調べてみました Opera Mini UAは Opera/9.80 (Android; Opera Mini/7.5.33361/30.3558; U; ja) Presto/2.8.119 Version/11.10 調べてみたら、いろんなヘッダーがあるようです HTTP_X_OPERAMINI_PHONE HTTP_X_OPERAMINI_PHONE_UA HTTP_X_OPERAMINI_UA 名前からして、ラッパー的なヘッダーですな ちなみにOpera MiniはサーバーでHTMLを変換する仕様なので、リモートアドレス/リモートホストはオペラのものになるようです REMOTE_ADDR
64.255.180.122
141.0.9.16 REMOTE_HOST
r07-10.opera-mini.net
s18-02.opera-mini.net
上記以外にも、あるけど元のIPアドレス(クライアント端末のIP)は次のヘッダに入っているようです
HTTP_X_FORWARDED_FOR |
|
2013 07,08 18:32 |
|
久しぶりにJSの勉強をしていたら、1,2年やらなかっただけで凄い進化をしつつ、
めんどくせいことになっているのね。。。 とりりあえず、本日の成果として iscroll.jsを使用するとURLバーが隠せない!挙動がやたら遅くなるのと、タップした時の反応がなくなる (- - ; ) それって思いつつも http://srobbin.com/jquery-plugins/pageslide/ FBでおなじみのサイドに、にょきってやるやつです |
|
2013 07,08 12:18 |
|
Dovecotのプロセスが多すぎて、他のプログラムが落ちているのでは?!という
はぁ、めんどくせい・・・月曜から、めんどくせい・・・ アクセス制限(iptablesで)をするという方法が一番望ましいと思うけど、 それも難しいので、とりあえずプロセス数を制限できればいいんじゃね?って思い調べてみました そしたら、やっぱりあります、他の方も同じようなことで苦労されているみたい Dovecotに対してPOPやIMAPの認証を何度も試すことにより、認証用プロセスを乱立させ、
ログインプロセスの処理にサーバーがおっついてこれなくなってしまうと、結果的に起動プロセス数が増え、
またDovecot認証用プロセスが利用するメモリ容量が増え、最終的にはサーバー自体が不安定になる事がある。
Dovecotに対して行われるログイン時の認証様プロセスは、各接続毎に作成する方法と、または複数の
特定数の認証用プロセスに全ての認証を処理させる方法があります。もし、Dovecotへの認証アタックにより
認証用プロセスが乱立してサーバーに影響を与えているようであれば、/etc/dovecot.confを以下の通りに
設定し、Dovecotの再起動をし様子を見てみましょう。
login_process_per_connection = no #追加 これで1プロセスで認証を行う用に変更 |
|
忍者ブログ [PR] |