読者です 読者をやめる 読者になる 読者になる

AWS上に、ディスクイメージから作成して動かしているBitnami wordpressのLet’s Encrypt(https化)を更新

sudo ./letsencrypt-auto renew --force-renewal -w /home/bitnami/apps/wordpress/htdocs

で更新が成功し、


sudo /opt/bitnami/ctlscript.sh restart apache

再起動することで、ブラウザから証明書を見た際、更新が確認できた

 

 

※最初、-wオプションを付けずに実行したら、以下のエラーが出てしまった。

Attempting to renew cert from /etc/letsencrypt/renewal/ドメイン.conf produced an unexpected error: Failed authorization procedure. ドメイン (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://ドメイン/.well-known/acme-challenge/U3ZG_cx_F84fETF9ayB0mlEyRZJqPWTTKhUKL2_JZRc: "<!DOCTYPE html>

 

All renewal attempts failed. The following certs could not be renewed:

  /etc/letsencrypt/live/ドメイン/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

 

IMPORTANT NOTES:

 - The following errors were reported by the server:

Domain: ドメイン

Type:   unauthorized

Detail: Invalid response from

http://ドメイン/.well-known/acme-challenge/U3ZG_cx_F84fETF9ayB0mlEyRZJqPWTTKhUKL2_JZRc:

 

To fix these errors, please make sure that your domain name was

   entered correctly and the DNS A record(s) for that domain

   contain(s) the right IP address.

 

 

これは、

teratail.com

こちらが詳しいが、

おそらく、HTTPサーバ(Apache、もしくはnginxなど)で設定したドキュメントルートと、letsenctypt-autoコマンドで指定したドキュメントルートが食い違っているのが原因です。」がまさに自分の場合でも該当したと思われ、-wオプションで、最初に証明書を設定した時と同じ、ドキュメントルートのパス(/home/bitnami/apps/wordpress/htdocs)を入れたらokだった。

mobilehubから作った場合の、cognito user poolにおける、ユーザー管理の注意点

通常、webサービスで使いたいと思った場合、email+passwordでユーザーを管理したいと思うのだが、cognito user poolだと、基本的に、username+passwordという管理体制がデフォルトとなっている。

 

awsももちろん、email+passwordで管理できるようにするためのことは考えていて、aliasという属性があり、これにチェックを付けていると、例えば、usernameを求められる所に、emailを入れても通るようになる。

 

ただ、若干そのあたりが厄介で、例えば、mobilehubからuserpoolを自動で作った場合だと、AttributesのemailにAlias設定がついているが、Requiredのチェックは付いていない。

 

そしてRequiredにチェックが付いていないと、php等のローレベルapiから、adminInitiateAuthなどの関数でアクセスしようと思った際に、usernameにemailの値を入れても、user does not existエラーが返ってきてしまう。

(※チェックが入っていれば問題なく通るので、PHPなどのローレベルapiで使いたければ、自前で別途poolを作る必要があるということ…)

 

 

また、Appsという項目があるが、js、並びにPHPなどのローレベルapiからアクセスさせたい場合、App client secretが使われているとアクセス出来ない(http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/setting-up-the-javascript-sdk.html

JavaScript SDK はクライアントシークレットのあるアプリケーションをサポートしていないため、[Generate client secret] チェックボックスは外しておく必要があります。」参照)

のだが、デフォルトでonになってしまっている。

 

これは、自分も最初全く気づかなかったのだが、複数アプリを作ることが出来るので(Apps の画面の下に、「Add another app」というボタンがある)、そこで、Generate client secretを外して作ったアプリのApp client idを使ってアクセスさせれば、js、並びにPHPなどのローレベルapiからアクセス可能になった。

 

あくまでmobile環境から使うだけであれば全く問題無いのだが、それをpcなど別デバイスからアクセスさせたいと思った時に、上記のような設定が必要になる。

 

 

※余談だが、mobilehubから設定したのではない、user poolを使おうとした場合、cognitoのtopから行ける、「Manage Federated Identites」→作成した物を選択→「Edit Identify pool」→「Authentication providers」→「Cognito」のUser Pool IDと、App Client IDを変更する必要があった。(元々は、mobile hubから作られた、user poolの物が入っているため)

また、もちろん、アプリ側も、例えばawsが作ってくれるサンプルファイルで言うところの、AWSConfiguration.swiftにUserPoolId、Client id、secretがあるので、そこも入れ替える必要がある。

cognito、phpからadminInitiateAuthを使うとAccessDeniedException

Fatal error: Uncaught exception 'Aws\CognitoIdentityProvider\Exception\CognitoIdentityProviderException' with message 'Error executing "AdminInitiateAuth" on "https://cognito-idp.ap-northeast-1.amazonaws.com"; AWS HTTP error: Client error: `POST https://cognito-idp.ap-northeast-1.amazonaws.com` resulted in a `400 Bad Request` response: {"__type":"AccessDeniedException","Message":"User: arn:aws:iam::xxxxxx:user/xxxxxxxxx is not authorized to pe (truncated...) AccessDeniedException (client): User: arn:aws:iam::xxxxxxxx:user/xxxxxxxx is not authorized to perform: cognito-idp:AdminInitiateAuth on resource: arn:aws:cognito-idp:ap-northeast-1:xxxxxxxx:userpool/ap-northeast-xxxxxxx - {"__type":"AccessDeniedException","Message":"User: arn:aws:iam::xxxxxxx:user/xxxxxxx is not authorized to perform: cognito-idp:AdminInitiateAuth on resource: arn:aws:cognito-idp:ap-northeast-1:xxxxxxx:userpool/ap-northeast-xxxxxxx"}' exception 'GuzzleHttp\Exception\ClientException' with message 'Cl in /Library/WebServer/Documents/bmj/aws_sdk/Aws/WrappedHttpHandler.php on line 192

 

というエラーが…。これは、該当するユーザーのIAMで、

AmazonCognitoDeveloperAuthenticatedIdentities

AmazonCognitoPowerUser

の2つをアタッチすればokだった。

 

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ファイルの書き換えを行い、あとは、

https://community.bitnami.com/t/how-to-disable-from-startup-stop-mysql-on-bitnami-ami-ami-6fc0f71b/4661/3

そのままだが、

 

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と同階層)に置き、アクセスさせないようにしたのと、AWSVPC上で、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

からのアクセスを弾くようにした。

 

ひとまずこれで問題がなくなればいいのだが…。