CentOS7の標準だとPHP5系だが、それだと古いのでremiリポジトリからPHP7系をインストールするようにしている。remiだと最新の7.3もRCの頃から出ていたのだが、勇み足で7.3rcにしたらいろいろ不具合があったので今まで7.2でしのいでいた。
とっくの昔にPHP7.3の正式リリースが出ていたので試しに予備の仮想サーバーに入れてみた。
WordPress 最新にしているから問題なし
CakePHP 2.10.8 そのままでは動かず、マイナーバージョンアップをしてみる
その他の自作ツール問題なし
16GBのシンプロビジョニング のディスクがいっぱいになってしまった。
上記スナップショットを残したままvmwareの仮想ディスクを拡張しようとした時のメッセージなのだがもう少しわかりやすく表示してほしいものだ。
インストラクションにある通り、スナップショットを全て削除してからディスクを拡張する。スナップショットの削除には２時間ぐらいかかった！
バージョンの問題なのか？以下のコードでFALSEにならないのにファイル書き出しされていない状態。相対パスであるなら大丈夫。昔からこうだったか、PHP7系になってから挙動が変わったのかは不明。
実験用ESXiなので実害はなかったのだが、DBインポートの際に通常なら３分程度で終わるのに、１０時間近くたっても終わっていなかった。
一旦中止して、再び実施するも同じ症状。ログには何も出ておらず。
Mariadbプロセスを強制killして、起動しようとするも今度はMariadb起動失敗！でログには何も出ない。Systemdになってからjournalctl -xeしろと言われるがあまり有益な情報がないのである。
結局困った時の/var/log/messages！みてみるとなんとDisk fullのエラーが起こっていた！初期設定では16GBのシンプロビジョニング なのでインポート時に100%を超えてしまった模様。
仮想サーバとはいえ監視設定をせねばと思った事態である。
長期間でみるともっと安いところはあるのだが、一時間単位の課金ができるのでAWSなみに細かく使えてなおかつ通信料による課金がない（制限はあるようだが）のが安心。
2Gプランで2.5円/一時間なので今までは一日単位で課金できるKagoya VPSを使っていたのだが、ConoHaのほうが短時間用途としてはよさそう。ディスクもSSDだし。
基盤はOpenStackを使っているらしく、APIで操作もできる（AWSと同じでセキュリティには注意しないとだめだが）
クラウド破産防止のため一定額チャージして、チャージが切れたら停止という課金形式を選べるのも安心ポイントである。
どこでも使える個人メモ用にpukiwikiをかれこれ１５年近く愛用しているわけだが、アップデートなんてないよねと思って探して見たらあった！
てな訳でアップデートしてみたが、今までページのリンクが絶対パスだったのが相対パスになっており、CDNを使っている関係でちとはまることになってしまった。
今までは絶対パスだったので一旦originに飛ばしてから判定できていたのだが、相対パスになったのでCDNからoriginサーバーに戻ってきてほしい場面で戻ってこなくなってしまった。
さてさてどうしたものか。とりあえずoriginのurlに打ち直すことで回避！
フィールド名やテーブル名に予約語を使うこと自体が問題であることは重々承知だが、既存システムだと簡単に帰るわけにはいかない。
そういう時にCakePHPではデフォルトでクオートしてくれるのだが、Spring JPAの標準であるHybernateではクォートしてくれない。
クォートしたいときは以下のプロパティを設定する必要がある。
jpa:
properties:
hibernate:
globally_quoted_identifiers: true
普通はDNSはプライマリーとセカンダリーを設定するのだが、そのせいで謎現象に遭遇したというお話。
プライマリーには8.8.8.8のgoogleのdnsを指定して、セカンダリーには自分で立てた内部用dns(内部IP以外は8.8.8.8に移譲している)を設定していた。
時折自分のドメインのDNSが内部のIPを示すことがあった。ブラウザを変えるとIPが変わったりするという超絶謎状態。
どうやらプライマリーで設定したDNSに接続できないか時間がかかる時はセカンダリーに接続し、そのセカンダリーに自分のドメインのサーバーのテストサーバーを登録して居たため謎の現象が発生していたようだ。
DNSの登録をプライマリーだけにしたら上記の現象は解消した。
前回の投稿でSpringBootとApacheを連携させローカルで動かしているのと同じ状況までもっていくことができた。
これで問題なしと思っていたら、リダイレクト時に元のポート番号まで含むかたちでリダイレクトするものだから、うまくいかない状況だということが判明した。
これはhttp://から始まりホスト名:ポート番号まで含んでリダイレクトしてしまっていることが原因なので、パス以下でリダイレクトするように設定を変更する。
server:
tomcat:
use-relative-redirects: true
Spring boot単体で起動するときはあまり問題にならないがApacheのmod_proxyで連携させるときにいろいろと問題がが出てきた。
まずはSpringBoot側のcontext-pathを/にしていた場合にはApache側で/を割り当てないかぎりcssなどの静的ファイルの読み込みに失敗する。
静的ファイルのみ別に配置して、そこのパスをApacheで割り当ているようにしてもよいのだが、お手軽にいくならcontext-pathをApacheとそろえることで解消できた。