AWS上に、ディスクイメージから作成して動かしているBitnami wordpressにLet’s Encrypt(https化)を導入
基本的に下記サイト様の通りでok
http://jmatsuzaki.com/archives/18680
(ただし、自分は「standalone」ではなく「webroot」指定とした)
また、「Webサーバーでhttps通信を有効化」以降でBitnamiの場合、
多少違うので注意が必要で、
http://weblabo.oscasierra.net/letsencrypt-2/
のサイト様の、「Apache 2.4 への設定」の項目の方が近い。
(ただ、設定は、
「httpd.conf」の「Include conf/extra/httpd-ssl.conf」のコメントアウトを外し、
「conf/extra/httpd-ssl.conf」の方に、SSLCertificateFileなどを書いていく必要がある点に注意。
また、もしかしたらそのままでも良いかもしれないが、
「VirtualHost _default_:443」の下に、「ServerName」という項目があるので、
そこは自ドメインに変更した)
ただ、上記を設定して、そのままリスタート
(「sudo /opt/bitnami/ctlscript.sh restart apache」)すると、
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
というエラーが出てしまう。
これはそのエラーの通り、443ポートが被ってしまっていると思われ、
http://dgz.jp/redminessl/
のサイト様が、Redmine向けではあるがやられていることが近く、
要は、「opt/bitnami/apache2/conf/bitnami.conf」
の方でもポート指定をしてしまっているのが原因なので、取り除く。
次に、aws側の設定になるが、
http://qiita.com/gakkie/items/d9b0799ce114c8df6f5d
のサイト様が詳しく、自分の場合はロードバランサーは入れていなかったので、
インスタンスに紐付いているセキュリティグループに、
443ポートを追加しただけで済んだ。
最後に、httpにアクセスされてしまった際のhttpsへの転送設定は、
https://www.riscascape.net/archives/3933
の 9. httpsへのリダイレクト & HSTS設定
を参考にさせていただいた。
その後再起動することで、問題なくhttpsから接続することが出来た。
実際の運用では、もちろん、wordpress自体の設定も色々変えないといけないのだが、
ひとまずここまでで…。
AWS bitnami wordpressのmysqlのダンプ、amazon RDSへの移行コマンド
mysqldump -u bn_wordpress -p bitnami_wordpress > /tmp/backup.sql
(※自分で付けたわけではないが、wp-config.phpを見ると、
テーブル名が「bitnami_wordpress」、ユーザー名が「bn_wordpress」となっていた)
mysql -u wordpress -p -h wordpressinstance.xxxxxxxxxxxx.rds.amazonaws.com wordpress < /tmp/backup.sql
(※amazon RDS作成時に、テーブル名もユーザー名も「wordpress」で作成している)
wp-config.phpファイルの書き換えを行い、あとは、
そのままだが、
sudo /opt/bitnami/ctlscript.sh stop mysql
sudo mv /opt/bitnami/mysql/scripts/ctl.sh /opt/bitnami/mysql/scripts/ctl.sh.disabled
でec2上で動いてしまっているmysqlを止めればokだった。
Appcelerator studioでalloyのviewを組んでいて遭遇したエラー
Error parsing XML file. element parse error: Error: invalid
または、
Error parsing XML file. element parse error: Error: attribute equal must after attrName
→全角スペースが入っていないか確認。
・Error parsing XML file. end tag name: Window is not match the current start tagName..
→タグが閉じていない(”/“ が付いていないとか)箇所が無いか確認
・Script Error Couldn't find module: alloy/controllers/.. for architecture: x86_64..
(新規に作ったviewを開こうとすると起こる)
→どういう訳か、もう一度ビルドし直すと解決。(インクリメンタルビルド的な事をしており、そこに1度では含まれないリソースファイルがあるとか?)
・Error: ETIMEDOUT..
at Timer.listOnTimeout (timers.js:119:15)
→アプリケーション再起動
・Cannot read property 'substring' of undefined..
→アプリケーション再起動(長時間起動していると起こるっぽい)
※その他、例えば、iosシミュレーター待ちみたいな状態になって止まってしまう(ビルド停止は出来るが)などがあったが、
そういったのは概ね、アプリケーションの再起動で直った。
AWS wordpress bitnami、アクセスが異常に遅くなる時があり、調べるとスパム攻撃を受けていた…
AWSに置いた、wordpress bitnamiが異様に遅くなる時がある。
(ただ、インスタンス再起動直後は問題なかった)
bitnami wordpressの場合の、apacheのアクセスログは、
https://wiki.bitnami.com/Components/Apache
によると、
/opt/bitnami/apache2/logs
にあるとのことで、そこにある、error_logを確認すると、
scoreboard is full, not at MaxRequestWorkers
というエラーが大量に起こっていた。
それで検索してみると、
https://community.bitnami.com/t/aws-wordpress-site-is-down-can-access-via-ssh-but-not-via-public-ip/41587/7
という、まさにぴったりなページが有り、access_logを確認すると、xmlrpc.phpに対して、スパムを受けている模様だった。
詳しくは、「xmlrpc.php」で検索してもらえるとスパム攻撃の詳細が色々出てくるのだが、xmlrpc.php自体は、メールなどから投稿をさせる仕組みを提供するphpファイルとのことで、そもそも恐らく自分では使わないので、
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
の内容の.htaccessをhome/bitnami/apps/wordpress/htdocs以下(xmlrpc.phpと同階層)に置き、アクセスさせないようにしたのと、AWSのVPC上で、xmlrpc.phpに大量にアクセスしていたipアドレスを拒否設定した。
(http://kawatama.net/web/aws/1852)
具体的には、
185.103.252.3
185.130.4.197
185.130.4.120
185.103.252.170
191.96.249.9
191.96.249.13
からのアクセスを弾くようにした。
ひとまずこれで問題がなくなればいいのだが…。
bitnami wordpress、phpファイルが1分程度キャッシュされて開発しにくかった問題
macローカルで、bitnamiのwordpressを入れて開発していたが、どうもphpファイルがキャッシュされる…。が、1分程度して読み込む際には必ず更新される。(※キャッシュ系のプラグインは全く入れていない状態)
静的なhtmlファイルだとキャッシュされなかったので、これはphp周りの設定で何かあるなと思い、色々見ていったが、結局のところ、php.iniの、
[opcache]
zend_extension=opcache.so
; Determines if Zend OPCache is enabled
opcache.enable=0
というように、
opcache.enable=0
を0にすればokだった。
ただこれはローカルだからで、AWSなどweb上に展開しているbitnami wordpressだと、mod page speedがデフォルトでオンになっているから、という原因もあるかもしれない。
もし更新されないようであれば、合わせて、
を参考に、offにしてみることや、あと、html自体のキャッシュoff設定(<meta http-equiv="Pragma" content="no-cache"> など)もした方が、さらにいいのかもしれない。
ng-repeatにbackboneのcollectionを渡すときは…
ng-repeat="item in collection.models"
というように、modelsを渡さないとダメだった…。
しかし、collectionだけでもエラーにならず、何故か4回繰り返されるという現象が起こっていた…。
どうも、とにかくエラーにならないで何となく動いてしまうという事に慣れないですね…(>_<)
【cordova】crosswalk導入の際に詰まったところとapkのサイズ
の
Upgrading Crosswalk in a migrated project
の手順を実行することで、自分のcorodovaプロジェクトに、crosswalkを入れ込む事が出来た。
(※crosswalkは、cordova/ARM版を入れた。x86(intel製)の端末も最近は増えてきているようですが、ARMの方が圧倒的シェアのようなので…)
「6. Build the projects in this order:」
の、3の手順では、例えば自分の環境では、
cp -a /Users/suzukikuniaki/Downloads/crosswalk-cordova-11.40.277.7-arm/framework/* platforms/android/CordovaLib/
のように指定した。
同様に4では、
cp -a /Users/suzukikuniaki/Downloads/crosswalk-cordova-11.40.277.7-arm/VERSION platforms/android/
のように指定した。
(※いずれも、DLフォルダにそのまま落としてきた物が入っているという想定)
また、6の所では、
「android update project --subprojects --path ./ --target android-21」
というようにする必要があった。
(パスの記述を修正、ダブルクォーテーション要らない)
(また、antが入っていない場合、こちらもまた、どこかに置いてそれをパスに追加する必要ありだった。自分はapache-ant-1.9.4を落としてきて、.bash_profileにパスを入れた)
ただ入れてみたところ、設定から見るアプリの容量は5MB→58MBに…
の
How big is the Crosswalk runtime, and how will it affect my application's size?
を見る限りでは、apkにすれば20MB程度の増加で済むとのことだったので、
早速、
cordova build --release android
でapkで出してみたところ、23MBでした…!
このくらいのサイズであれば、何とか使えそうですね。
動作させて見たところ、元々、遅めの端末を持っていないので、
速度面の改善は正直わからなかったのですが、
ちょっと位置がずれているとか、そういう問題は見えなくなっていました。
※Androidでもサクサク動くHTML5ハイブリッドアプリの作り⽅
のスライド21によると、4.4以降では、むしろcrosswalkの方が若干遅い場合もある
(標準で動作するのが旧webview→chromium製の物になったためと思われる)
とのことなので、最終的に導入するかは、色々動かしてからにしたいと思います。
※その後ストアに出してみると、ローカライズはしていないのに、多数の言語が登録されているという現象が…これは、
platforms/android/CordovaLib/xwalk_core_library/res
以下にある、
values-am、values-ar…など、「values」以外のローカライズフォルダを全て削除してからapk化することで、きちんと、「ローカライズ デフォルトの言語のみ」になった。