Google Driveで共有するため、Googleアカウント(Gmail)を入力して「送信」ボタンを押下すると、「○○さんとは共有できません」のエラーが発生した。原因不明のためGoogle Oneサポートに問い合わせした結果、共有先アカウントが、共有元アカウントをブラックリストに誤って登録していたことが原因であることが判明。誤操作とみられる。
共有先アカウントで下記URLにアクセスしてブラックリストを確認し、必要に応じて解除すれば解消した。
Google Driveで共有するため、Googleアカウント(Gmail)を入力して「送信」ボタンを押下すると、「○○さんとは共有できません」のエラーが発生した。原因不明のためGoogle Oneサポートに問い合わせした結果、共有先アカウントが、共有元アカウントをブラックリストに誤って登録していたことが原因であることが判明。誤操作とみられる。
共有先アカウントで下記URLにアクセスしてブラックリストを確認し、必要に応じて解除すれば解消した。
XREAで無料SSLが使用できるようになりました。昨今、GoogleChromeを皮切りに、入力フォームのあるウェブサイトでSSL/TLS(https)通信が有効になっていない場合、画面に警告が出るようになるらしいですね。この流行には乗るしかない! ということで、早速、調べてみたのですが……なんと、XREAで言う所のMainには無料SSLが適用できない制約事項があるではないですか。Mainとは、public_html直下にWordPressをインストールしている状態を指します。これを、何とかサブディレクトリ(Sub)に移設してみようと思います。因みに、私はMainに独自ドメインを設定しています。
公式Wikiに似たような手順はあるのですが、実際にはもっと単純です。手順では、サブディレクトリを手で作ることになっていますが、XREAではサブディレクトリ=ドメインとなるので、実質、WordPress自体の設定変更は不要です。(URL自体は変わらないため)
XREAのコンパネから、Mainを空白にして、SubへMainに設定されていた独自ドメインを設定して、反映してやります。そのあと、同じくコンパネから無料SSLを有効にしてやります。
ドメイン設定が反映されて、public_html/jikkenjo.netディレクトリが作成されたら、public_html直下にあったWordPressファイルをコピーしてやります。ftpでやると、1ファイルずつコピーする動きになるので、ssh接続してからcp -rで実施すると一瞬で終わって良いです。[cp -r wp-* jikkenjo.net/][cp index.php jikkenjo.net/][cp .htaccess jikkenjo.net/]で取り合えずOKだと思います。気になるファイルは個別に移動させてください。
後は、Really Simple SSLをインストールして終わりです。独自ドメインが変更差異を吸収してくれたので、意外に楽だった……。
と、忘れてた。GoogleAnalytics側の設定をhttp→httpsに変更しておかなければなりません。
前々から非常に困っていた事象がWordPressの手動アップデートで訳も分からず解消したので記しておきます。
タイトルの通りです。WordPressの管理画面で「ダッシュボード>更新(update-core.php)」にアクセスした瞬間、MySQLのwp_optionsテーブルでオーバーヘッドが増大し、管理画面だけではなく、全画面で500 Internal Server Errorになってしまいます。WordPressのデバッグモード等で確認してみると、どうやら、Apache(PHP)からMySQLへクエリを投げた時にTimeoutに陥ってエラーとなっているようでした。phpMyAdmin等で「最適化」によりwp_optionsのオーバーヘッドを取り除いてやると、対症療法的には解消します。いくら調べても根本原因に辿り着かなかったことと、更新画面にアクセスしなければ発生しないことから、数年もの間(長い!)直視しないでおいた問題でした。
冒頭でも触れたように、時代錯誤にもWordPressを手動更新してやれば解消します。自動更新機能が存在しなかった時代のWordPressから、自動更新が存在する時代のWordPressに更新する手順として、WordPressの公式ドキュメントに整理されています。手順の中で、旧ファイルを消すという点がポイントだったようです。
数年続いていた本事象により、全くWordPressが更新できなくなったことで、セキュリティ的に心配だったので、何度か手動での更新はしていました。その際、最新ファイルで上書きすることだけで対応していました。そのような、旧ファイルを消さない手順では解消しませんでした。
解決した今も、相変わらず原因は不明だったわけですが……。
XREAがサーバ老朽化に伴うマイグレーションを行いました。s353サーバに収容されていた当ウェブサイトも今日当たりました。で、同時にWordpressが動かなくなっていました……。色々と面倒だったので記しておきます。
Sorry. We are under maintenance.
移行前のウェブ領域は残されるようです。そのため、VALUE-DOMAIN以外のドメインレンタルサービスを使用していて、DNSレコードのIPアドレス修正が漏れていた場合は上記メッセージが表示され続けます。当ウェブサイト(jikkenjo.net)はVALUE-DOMAIN(eNom)だったので自動切換えでしたが、一部、他社からレンタルしているドメインを修正し忘れていて、本事象に当たりました。
他にも、ページが途中までしか表示されない事象が発生しました。吐き出されたHTMLソースを見ると、何の前触れもなくぷっつり切れていました。原因不明だったので下記対処をしましたが、結果として、DBをphpMyAdminでanalyze/optimizeすれば解消しました。詳細は不明ですが、恐らくどこかのレイヤでタイムアウトに引っかかってしまったのではないかと思われます。マイグレーション作業として行われたであろうDB移行が、物理移行(ファイルシステムごとコピー)ではなく論理移行(MySQLのダンプ・リストア)だったため、統計情報が更新されなかったと考えられます。(MySQLのバージョンが上がったので、物理移行は無理だった? それにしても、初回のanalyzeくらいは実行しておいてほしかった。)
wp-config.php に下記文言を追記してやると、Wordpressの内部エラーが出力されるようになります。私の場合は、「DBサーバとの接続が確立できませんでした」的なメッセージが出ていました。(connection refusedだったかな……)
define('WP_DEBUG',true);
久しぶりに技術記事です。夜な夜な友人とプレイしているfactorioが、普通にマルチプレイでやるとNW遅延が大きすぎるということで、流行りと無料キャンペーンに乗ってAWS/EC2にfactorioサーバをたててみました。
sshクライアントにTeraTermを使う場合は、サーバ名を入力後、ユーザIDとダウンロードした鍵ファイルを指定して接続すればOKです。
下記の様に、/home配下に展開して起動してやっても出来なくはありませんが、serviceで起動してやった方が安定します。
tar xvfz factorio_headless_x64_0.14.22.tar.gz cd factorio/bin/x64/ ./factorio --create ../../saves/hogehoge.zip ./factorio --start-server ../../saves/hogehoge.zip
もう少しこだわる人は下記の手順メモを参考にしてください。
-- serviceに登録するプロジェクトをダウンロードするためgitをインストールします。 $ sudo yum install git -- headless版のfactorioを/opt配下に展開します。 $ cd /opt/ $ sudo tar xvfz ~/factorio_headless_x64_0.14.22.tar.gz -- 英語版Wikiに従ってfactorioユーザを追加します。 -- これを怠ってしまうと、後々factorioユーザを前提とした設定で面倒です。 $ sudo useradd factorio $ sudo chown -R factorio:factorio factorio/ -- serviceに登録する有志のプロジェクトをダウンロードしてきます。 $ sudo git clone https://github.com/Bisa/factorio-init.git $ sudo chown -R factorio:factorio factorio-init/ -- 意図がわかりませんでしたが、README.mdに書いてあったので設定。 -- 設定後にbashを再起動します。 $ sudo ln -s /opt/factorio-init/bash_autocomplete /etc/bash_completion.d/factorio $ echo "source /opt/factorio-init/bash_autocomplete" >> ~/.bashrc $ exec bash -- serviceを登録してやります。 $ sudo ln -s /opt/factorio-init/factorio /etc/init.d/factorio $ sudo chmod +x /opt/factorio-init/factorio -- 自動的にfactorioをUpdateするスクリプトもダウンロードしておきます。 -- 手動でやるという人は不要です。こちらも有志のプロジェクトです。 $ sudo git clone https://github.com/narc0tiq/factorio-updater $ sudo chown -R factorio:factorio factorio-updater/ $ ll total 16 drwxr-xr-x 5 root root 4096 Apr 2 05:38 aws drwxr-xr-x 4 factorio factorio 4096 Apr 20 00:01 factorio drwxr-xr-x 3 factorio factorio 4096 Apr 20 00:05 factorio-init drwxr-xr-x 3 factorio factorio 4096 Apr 20 00:29 factorio-updater -- ↑こんな感じの状態になっていればOKです。 -- ここからはfactorioユーザで作業した方が効率的です。 $ sudo su - factorio -- exampleを参考に設定ファイルを作成します。 $ cd factorio-init/ $ cp -p config.example config $ vi config -- 触るところは基本的にありませんが、先ほどの手順でfactorio-updaterをダウンロードした人のみ下記を設定します。 -- UPDATE_SCRIPTの設定と、USERNAME/TOKENにfactorio公式のアカウントを設定すればよいと思います。 # absolute path to the factorio-updater script UPDATE_SCRIPT=/opt/factorio-updater/update_factorio.py # Note that if you set HEADLESS=1 the username/token will not be used as the headless # download is provided free of charge HEADLESS=1 UPDATE_USERNAME=you UPDATE_TOKEN=yourtoken UPDATE_EXPERIMENTAL=0 UPDATE_TMPDIR=/tmp -- serviceに正常に登録できたことを確認します。 $ service factorio help -- 自動更新の設定が正常にできたことを確認します。(当然、最新です。) $ python update_factorio.py -l Available packages: core-linux_headless64 $ python update_factorio.py -p core-linux_headless64 No updates available for version None (latest stable is 0.14.22). Did you want `--experimental`? $ python update_factorio.py -p core-linux_headless64 -f 0.14.22 -x No updates available for version 0.14.22 (latest experimental is 0.14.22). -- factorio本体の設定を行います。適宜修正してください。 -- name/descriptionあたりは全員変更の必要があると思います。 -- 友人だけのサーバの場合は、public/game_passwordあたりを設定してください。 $ cd /opt/factorio/data/ $ cp server-settings.example.json server-settings.json $ vi server-settings.json -- factorioの初期設定をするため、初回のみセーブファイルを作成する手順が必要です。 $ cd /opt/factorio/ $ ./bin/x64/factorio --create ./saves/mysavegame -- serviceで起動してやります。 $ service factorio start
下記に途中で出たエラーと対処法を記しておきます。(メッセージを読めば分かるので、私は特にハマりませんでしたが)
-- 設定ファイルが不足しています。exampleを参考に作成してください。 $ service factorio start Could not find factorio server settings file: /opt/factorio/data/server-settings.json Update your config and point SERVER_SETTINGS to a modified version of data/server-settings.example.json -- 初期設定のため、初回のみセーブデータを手動で作ってください。 $ service factorio start Could not find factorio config file: /opt/factorio/config/config.ini If this is the first time you run this script you need to generate the config.ini by starting the server manually. (also make sure you have a save to run or the server will not start) Create save: sudo -u factorio /opt/factorio/bin/x64/factorio --create /opt/factorio/saves/my_savegame Start server: sudo -u factorio /opt/factorio/bin/x64/factorio --start-server-load-latest (If you rather store the config.ini in another location, set FCONF='/your/path' in this scripts config file)
Windows端末でJMeter走行中にJMeter自身のExceptionが「結果をツリーで表示」リスナーの結果画面に表示される場合があります。これは、スレッド数を多くした場合や、画像やjavascriptやcssが多い場合に発生します。最終的にはクライアント端末の同時接続数を超えたことが原因です。
Windowsのレジストリに項目を追加することで、本事象を回避することが出来るのでメモしておきます。下記内容をテキストファイルに保存して、拡張子を.regとして実行すれば簡単です。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "MaxUserPort"=dword:0000FFFE "TcpTimedWaitDelay"=dword:0000001E
謎のエラーが出てdocomoアドレスをGoogleGroupsに登録できませんでした。
エラーメッセージをパッと見て思いついたのが、登録済みGmailのGoogleアカウントに、追加しようとしているdocomoアドレスを結びつけている可能性でした。
エラーメッセージを見る限り、「予備のメールアドレス」の部分が妙に引っかかります。特に原因特定するつもりもありませんが、同様のメッセージで悩んでいる人のためになるかもしれないと記しておきます。
招待状が送信されませんでした 新しい招待状が送信されませんでした 1 人は既にグループのメンバーです。指定されたメールアドレスがこのユーザーのメインのメールアドレスか予備のメールアドレスかは不明です。
全く興味ありませんでしたが、知識として興味があったので試してみました。色々と大変でした。
まずはamazon.comのアカウントを取得します。商品を購入するamazon.co.jpのアカウントではありません。襷に長し感は有りますが、ここで取得するアカウントはAWSのアカウントです。AWSで提供されるサービスが多すぎて意味が分からなくなります。
ルートユーザ(今取得したアカウント)でアフィリエイト用キーを発行しても良いのですが、「ルートユーザから払出した子ユーザから発行したアフィリエイト用キーを使うのが最近の流行りだよ!」とAmazonから勧められるので大人しく従います。サービスメニュー(サービスが山ほどあるので頑張って見つけてください)から「IAM(正式にはアイアムと発音)」を選択します。サイドメニュー(ダッシュボード)より「ユーザ」を選択します。新規ユーザを払出して、アクセスキーとシークレットキーを取得します。シークレットキーは後では2度と確認出来ないのでメモっておきましょう。
次に、払出した子ユーザに対して権限を付与します。ユーザ詳細ページの「アクセス許可」タブから、「ポリシーのアタッチ」をして、「AdministratorAccess」を付与します。(何の権限が最低限必要なのか、最後まで不明でした。色々組み合わせて試したのですが分からず。全権限付与しちゃうと、子ユーザを払出する意味は無いのかも。)権限が足りない場合は、後で実施するAmazonJSの使用中に下記エラーが発生します。後で分かったのですが「Amazon EC2 Container Service」権限さえあれば良いと思います。
Amazon Product Advertising APIのエラー
UnauthorizedOperation
Your AccessKeyId is not authorized to perform this operation. Please check IAM policies for the Access Key.
支払先等を設定するためのアカウントも個別に取得する必要があります。淡々とアカウント登録を進め、トラッキングID(日本アカウントの場合は、末尾が「-22」となります)を取得して完了です。ちなみに、銀行振替の設定だと面倒そうで、Amazonギフトとして受け取る設定だとワンクリックで設定完了しました。アカウントが正常に設定できていないと、後で実施するAmazonJSの使用中に下記エラーが発生します。
Amazon Product Advertising APIのエラー
AWS.MissingParameters
リクエストには、必要なパラメータが含まれていません。必要なパラメータには、AssociateTagなどがあります。
AmazonJSをインストールして設定ページで、アクセスキー、シークレットキー、アソシエイトタグを入力します。
記事の執筆画面のメニューにAmazonマークが現れており、URL入力等で簡単に記事へアフィリエイトリンクを挿入できてしまいます。折角なので、最後に最近読んで面白かった漫画のアフィリエイトを貼っておきます。
pg_dumpでは-tオプションで単一または複数のtable/view/sequenceを指定して定義の抽出が可能ですが、functionの指定はできません。これを解決する、裏技チックな方法が英語ページにしか掲載されていなかったので、日本語ページの一人目になるべく本記事を執筆しました。
pg_dump -Fc -s | pg_restore -P 'funcname(args)' > function_define.dmp
-sオプションでスキーマ(定義)のみを抽出します。(ここでいうスキーマとは、テーブルの完全修飾名の前半に使う名称(schema)ではないので注意。単なる定義情報(雑に言うとcreate table)のことを指します。この注意事項は本家にも記されています。ややこしいですね。)
これと–schemaオプションと混乱しないでください。”schema”という単語を異なる意味で使用しています。pg_dump
結果をパイプでpg_restoreに繋いでいます。pg_restoreはcustom形式しか処理できないため、-Fcオプションを付与しています。(デフォルトはplainです。)
-Pは名称を指定してcustomからfunctionの定義を取り出すことができます。また、pg_restoreは特に接続先データベースが指定されていない場合、標準出力にplain形式で吐き出すため、リダイレクトでファイルに出力しています。
データベース名が指定された場合、pg_restoreはそのデータベースに接続し、アーカイブを直接そのデータベースにリストアします。 データベース名が指定されなかった場合は、データベースを再構築するために必要となるSQLコマンドが含まれたスクリプトが作成されます(ファイルもしくは標準出力に書き出されます)。pg_restore
functionに引数(args)がある場合、正しい引数の数だけ、型を指定してやる必要がありますので注意が必要です。不明の場合は下記コマンドで確認できるでしょう。
pg_dump -Fp -s | less
私の環境では2回以上-Pを指定した場合、最後に指定したfunction以外が無視されました。そのため、下記のように工夫する必要があります。
pg_dump -Fc -s | pg_restore -P 'funcname(args)' > function_define.dmp pg_dump -Fc -s | pg_restore -P 'funcname2(args)' >> function_define.dmp pg_dump -Fc -s | pg_restore -P 'funcname3(args)' >> function_define.dmp
最終的な出力ファイルを見ると、SETが重複して出力されていますが、特に弊害はありません。
xreaが大規模更改にあたり、各ソフトウェアのバージョンがドラスティックに変わりました。MySQLも大幅にバージョンアップするため、本ブログ(Wordpress)のデータがすべて削除されました。xrea運営が作業前に取得してくれていたdumpファイルを元に無事復旧できたのでメモしておきます。
蛇足ですが、XREA自体がそもそも上級者向けの低価格低サポートなサービスだっただけに、殆どの方は自分で解決されているようでした。また、公式サポートフォーラムでも技術者らしい冷静な対応をされている方ばかりだったので、なんだか安心しました。
[usename]や[dbname]やサーバ名やファイル名は適宜読み替えてください。
xreaのコントロールパネルから、過去にWordpressで使用していた名前でDBを作成します。パスワードも過去(Hint:初期パスワードはFTPパスワードの前8文字)と同じにしてください。稀に、xreaの更改作業を乗り切ってしまうDBもあるそうですが、間違いなく中途半端にしか復元できていないため、一旦削除してから再作成(空のDBを用意)してください。
サーバにsshで接続します。xreaのコントロールパネルから「ホスト登録」をお忘れなく。出来ない場合は1~3分待ってください。
ssh -l [username] sXXX.xrea.com
公式からutf8への変換が必要とアナウンスがあるため、dumpファイルをutf8に変換します。nkfでいけます。
MySQL4以前などの古いデータベースからデータは完全には引き継げませんので、データベース内のデータが一旦空になります。
特に文字コードはUTF-8が標準となりますので、そのまま引き継ぐと不具合が出る可能性があります。
MySQL/PostgreSQL/Apache/PHPのバージョンアップメンテナンスについて
ll cd _DB_BACKUP_XREA_UPGRADE/ ll nkf -w mysql_[dbname].dump > mysql_[dbname].dump.nkf ll view mysql_[dbname].dump.nkf
中身を見て問題なさそうならインポートします。先ほど設定したDBのパスワードを聞かれます。
mysql -u [dbname] -D [dbname] -p < mysql_[dbname].dump.nkf
特にエラーが起きなければ以上となります。念のためレベルで、インポートしたDBを確認してみてください。
mysql -u [dbname] -D [dbname] -p
use [dbname] show tables;
phpMyAdminを使用する場合は再インストールが必要です。公式では下記のように説明されていますが、私はコントロールパネルで「インストール」を選択するだけでいけました。
1、ファイルマネージャーもしくは、ご利用のFTPクライアントから、現在のディレクトリ「./public_html /log /phpmyadmin_」等に名前を変更します。
2、XREAサーバー管理画面二ログインし、「データベース」メニューから
「■PhpMyAdmin自動インストール(MySQL管理) 」項目の「インストール」ボタンをクリックします。
3、「./public_html /log /phpmyadmin」が生成されたことを確認されましたら、ログインします。
【公式】XREAサーバー:最新の環境へのアップデートメンテナンス関連