VPSサーバーのOSをアップグレードすることにしました。当サイトはDebian GNU/Linuxを使っています。今までApache＋MySQLで動かしてきましたが、Debian 10がリリースされたこともあり、これを機会にMySQLをやめてMariaDBに変更します。
MariaDBはMySQLと互換性が高く保たれているそうなので、一応バックアップは取るものの、トラブルが無ければすんなりと行けるハズです。
Apacheは継続して使うつもりなので（Nginxにはしない）、懸念するところはMySQLのデータをMariaDBに上手く移行させられるか？というところです。
4年ほど前に知り合いから相談を受けて、はてなブログの操作を確認する為に無料版で公開し始めたところ、意外と書くテーマがあってコツコツ続けられたのでそこそこ記事がたまって来ました。
当初は操作性や機能を確認する目的だったのですが、独自ドメイン（サブドメイン）をDNSで割り当ててみたくなり、有料版（はてなブログPro）をすぐに使い始めたのですが、はてなの対応がイマイチ良くないこともあり、時代の流れ上当然であるSSL（HTTPS）にも対応してくれないし（今日現在まだ有料版のPROは対応していません。
しかも逆撫でする様に無料版はSSL対応済みだという現状・・）。これはダメだなと、はてなブログを捨ててWordPress環境に移すことにしました。少なくとももはやお金を払って使用する価値は私にはありません。契約期間が終わったらさいならです。
幸い、当サイトと同様に自前のWebサーバーはSSL対応の下地は出来ているし、IPv6対応も済ませているので、メインとなる面倒な作業はWordPressの動作環境を整えることと、既存コンテンツ（記事＆画像）を移すことが課題でした。
当初思っていたよりも容易に移行出来たので一日で引っ越し出来ました。WordPressマルチサイトモードの検証という寄り道が無ければ半日で終わったかも知れません。複数のサイトをまとめるためにWordPressマルチサイトモードに期待していたのですが、パーマリンク動作が怪しいので今回はパスする事にしました。マルチサイトを必要とするユーザー数は圧倒的に少ないのでバグがまだ残っている可能性が高いと思います。
さて二年ほど前に当サイトをSSL対応させた時の記録は端折っていてちょっと不安でしたが、結局Let’s Encrypt公式ポータルを参照しただけでSSL証明書の組み込みが出来ました。しかし物忘れも激しくなって来ましたし、先々きちんと思い出せるか自信が有りません。それに次回の作業はもっと時間短縮させたいので自分の為に要点だけ残しておきます。
自分なりに敢えて不要な部分は残さずわかりやすくしているつもりなので、この記し方が誰かに役立てば何よりだと思います。（だいた私のノートは子供の頃からこんな感じです。詳しい解説は教科書や参考書を読めば良いですからね。Let’s Encryptなら公式サイトに書いてある事が一番信用出来ます。）
前回の作業記録
テスト環境のインターネット接続に使用しているISPを、ASAHIネットに変更したので、せっかくならネイティブIPv6接続が可能なIPoEで接続してみようと、ブロードバンドルーターを変更してみました。
片手間で時間をかけずにリサーチしたので、結果的には、中途半端な結果に終わってしまいましたが、IPv6がようやく積極的に使用できる（メリットもある）段階に来ているので、ここいらでちょっと触れておくことも先々の為には意味があったと思います。最近インフラ系の仕事から離れているので、少しずつでもついて行かなければ。
現時点はASAHIネットが「IPv4 over IPv6」をサポートしていないので、IPoEによるネイティブなIPv6接続はできるものの、そのままではIPv4サイトに接続することが出来ないという結論に至り、今まで通りPPPoEによる接続に戻すことになりました。
よくよく確認したら、きちんとASAHIネットのサイトに記載されていました。
アクセス先のサービスがIPv6に対応している場合のみ、IPv6で通信いただけます。IPv4でのインターネット接続には、別途IPv4PPPoEの設定が必要です。ご注意ください。
今回使用したブロードバンドルーターは、Wi-Fi対応のI-O DATA WN-AX1167GR2という機種で、IPoEに対応しているWi-Fiルーターとしては、比較的購入しやすい価格でありながら評価も高い機種なので、組み合わせるISPをキチンと選べば、IPv6による高速接続と、現状通りのIPv4接続を維持できる良い機種だと思われます。 続きを読む
知人がPCを買い替えたそうです。
Windows 7のPCを5年程使ってきたそうなのですが、ここんところ非常に遅くなり、固まったりして強制的に電源を切らざるを得なくなったりと、不具合続きだったのが、とうとうWindowsが起動するのに「運」が必要になったりと、実用に耐えなくなったそうで買い替えを決意したそうです。
近場なら遊びに行くついでに点検してあげられるのですが、確実に泊りがけの訪問になるのでそれはかないません。知人も周囲に頼れる人がいないので買い替え時期だと割り切って買い替えたそうです。（メールのセットアップ等はショップの訪問サービスを利用したそうで古いPCも処分してもらったそうです。）
その知人から、以前のPCで使用していたExcel文書（おそらくOffice 2010を使用）を開くと、Windowsのシステムフォント（ゴシック体）に置き換えられてしまい、作成したイメージ通りの印刷が出来ないと相談を受けました。知人いわく、自分でフォントを追加するなんてことは自分では出来ないので元から入っていたはずだと。今回のPCはWindows 10 + Office 2016を購入したそうなのでOSとOfficeのバージョンが上がった為に古いフォントが入っていないのかも知れません。
しかし、Excelは開いた時に使われているフォントが無いと置き換えてしまうので、使っていた（使いたい）フォントの名前が分かりません。これは困ったことです。（PDFなら調べようはあるんですけどね・・）
手がかりはExcelファイルと、作品として印刷したものの写真が残っています。
どちらからアプローチしようかな・・
EC-CUBEを使用しているクライアントより、カラーミーへの移転相談がありました。これを機会に全ページSSL対応させたいとのことです。ECサイトにとってはSSL化は急務なのかも知れません。
まずはそれぞれのECサイト用エンジンの違いについて把握しておく必要があります。
http://example.com/products/detail.php?product_id=100
?pid=100000001
調べた限りでは、カラーミーへの商品登録時には商品IDは自動採番されるらしく、任意の番号を付与することが出来無さそうです。面倒ですが商品個別のリダイレクトを定義して、適切なページに転送させる必要がありそうです。
確実な方法としてApache modrewriteを使って301リダイレクトを行う検証をしてみました。既にこのEC-CUBEのサイトは運用年数も長くそれなりのSEO評価を得ているので、適切にリダイレクトしてやればその評価を継承できます。
幸い.htaccessによるmod_rewriteエンジンが使用出来ることは確認済みです。
EC-CUBE側のサイトで、productsディレクトリに.htaccessファイルを配置していくつかの転送指示を記してみました。今回はQUERY_STRINGを使いました。
EC-CUBE側の商品アドレスにアクセスすると、カラーミー側の新商品ページに転送されることが確認出来たので手応えとしては良さそうです。
[crayon-5d610516afc61005494012/]
上の例ではEC-CUBE側でproduct_idが134、140、199の3商品のみを転送する例ですが、商品数が50以上あるので、それぞれについての転送を記述しなくてはならず、それだけこの.htaccessのサイズ肥大が気がかりではあります。