Answorz!へようこそ。 はじめまして、管理人の もっさん先輩 です。「Answorz」と書いて「アンサーズ」と読みます。「Answ orz」を見てピンときた方がいれば、伝わったかもしれません。このブログでは、プログラムに関係するQ＆Aを書いて、何度でも使って頂けるサイトを目指していこうと思います。みなさんの為になれば良いですし、自分の為でもあります。 【超重要】本サイトの利用により生じたいかなる損害についても、当方は一切責任を負いません。ご利用は自己責任でお願いします。 2022年6月10日 もっさん先輩
（１）一先ずコピー先の kusanagiサーバー を1台用意した。 （２）kusanagiの管理画面を表示した。ベーシック認証には、rootと契約時のパスワードを入力した。 http://163.44.111.xx:60000/ （３）コピー元のドメイン、メールアドレスを入力した。 （４）「WordPress管理画面URL」にアクセスした。 KUSANAGIユーザー名：Kusanagi KUSANAGIユーザーパスワード：xxxx （５）ワードプレスをインストールした。 サイトのタイトル：answorz ユーザー名：mossan パスワード：!xxxxAk メールアドレス：xxxx@yahoo.co.jp （６）ワードプレスに SSH（Teraterm） でログインした。 ホスト名：163.44.111.xx ユーザ名：root パスワード：なし ・sshを使用 ・鍵ファイル設定 （７）「All-in-One WP Migration」をインストールするが、「有効化」すると書き込み権限で不具合が発生するので以下の手順で行う。 ①「All-in-One WP Migration」をインストールする。 ②権限つける。 chmod a+w -R /home/kusanagi/answorz.com/DocumentRoot/wp-content ③「有効化」する。 （８）サイトのインポートを行う。 ダイレクトモードに変更する。chmod a+w /home/kusanagi/answorz.com/wp-config.phpvi /home/kusanagi/answorz.com/wp-config.php#define(‘FS_METHOD’, ‘ftpext’);define(‘FS_METHOD’, ‘direct’); メモリー、ファイルサイズ、タイムアウトを変更する。vi /etc/opt/kusanagi/php.d/php.inimemory_limit = 3000Mpost_max_size = 3000Mupload_max_filesize = 3000Mmax_execution_time = 1200max_input_time = 1200 systemctl restart php-fpm リバースプロキシも変更する。vi /etc/opt/kusanagi/nginx/nginx.conf#client_max_body_size 20M;client_max_body_size 3000M; vi /etc/opt/kusanagi/nginx/conf.d/0644773a5317d4131b11645a.conf#client_max_body_size 16M;client_max_body_size 3000M; kusanagi nginx –testkusanagi nginx –reload （９）All-in-One WP
ConoHaのワードプレスを他のサーバーに移行するには？ Read More »
この「データビット７」と「パリティーEVEN」は超重要です。これがないと、OPOS の ClaimDevice で OPOS_E_TIMEOUT になってしまうのです。私が購入した REX-WF60 には「データビット７」が設定できなかったのです（泣）。ＲＳ－ＥＴ６２では繋がりました。カタログを見ると「WF60」以外は「データビット７」設定できますね。気をつけてね。 その調査している間、USB-RS232C変換ケーブルでも試しました。PC → USB-RS232C変換ケーブル → 自動釣銭機ではアクセスできるのですが、PC（Virtual COM ネットワーク）→ USB-RS232C変換ケーブル → 自動釣銭機だとアクセスできませんでした。これも以下のように構築すればアクセスすることができました。 COM3 が USB-RS232C変換ケーブル。それを VirtualCOM の COM4⇔COM5 の COM4 に接続して、COM5 からデータを送って使ってアクセスするコマンド。 COM5 → COM4 → COM3 → 自動釣銭機
自動釣銭機でClaimDeviceでOPOS_E_TIMEOUTしてしまう Read More »
（１）まず前回作成したイメージ（AMI）を削除した。その際にスナップショットも一緒に削除した。→イメージを作成した際にスナップショットも作成されというわけですね。 ・AMI・・・スナップショット・インスタンス・・・ボリュームという理解でいくか （２）今回はバックアップとして「イメージを作成」し完全バックアップを作成しようと思います。 （３）イメージの作成・「イメージ名」に「backup」と入力した。・「終了時に削除」の有効化にチェックをした。※ここに「イメージの作成プロセス中に、Amazon EC2 は上記の各ボリュームのスナップショットを作成します。」がありましたね。２回目にしてようやく気付く。「イメージを作成」ボタンを押しました。 （４）「AMI を現在作成中 ami-0b050d7dbe377ce5d インスタンス i-01ed4bb82b5d9ac80 から。インスタンスを削除したり、この AMI に関連する他のアクションを実行したりする前に、AMI のステータスが [利用可能] であることを確認してください。」とコピー中なので待ちます。 （５）３分後。「保留中」から「利用可能」になりました。 （６）スナップショットはこれのことですね。２週目にしてようやく理解しました。「AMI-backup」と名前をつけました。 ここまででいえることは、私はただAMIでバックアップを取った。なにか元のインスタンスで失敗たら、このAMIを使えば元に戻るという理解にしておこう。 （７）修正するインスタンスを停止させた。 （８）「ボリューム」をデタッチした。１回目でデタッチできました。 「使用可能」を確認 （９）「ボリュームのアタッチ」します。インスタンス起動中でもアタッチできました。正常に動くインスタンスの「/dev/sdf」を選択します（データボリュームの場合は /dev/sd[f-p]）。とありますね。 （１０）ボリュームを調べる。AWSでは「/dev/sdf (attached)」となっているが、実際は「/dev/xvdf」になっていた。↑でも「/dev/xvdf」に変更されることがあるといっていたのはこのことです。 （１１）「/dev/xvdf」をマウントする。 （１２）ここで、ようやくhosts.allow 書き換えです。 （１３）IPの追加が終わったらアンマウント （１３）起動中にデタッチできました。 デタッチするとこんな状態です。 （１４）これを元のインスタンスにアタッチします。※デバイス名には「/dev/sda」を選択します。 （１５）これでインスタンスを開始しました。 （１６）SSHでアクセスできることを確認できました。
AWS EC2 に ssh で接続できなくなった（hosts.allowが失敗した）２ Read More »
