5丁目通信(仮称)

とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。

タグ: 失敗

  • AdobeのCreative Cloud が起動できなくて、アドビ謹製のアンインストールプログラムでアンインストールしてから再インストールして起動できた話し

    アップデートの対象になったどうかは知らないけど、自動的に(勝手に)アンインストールされて、そのままAdobeのCreative Cloudがなくなっていた。Creative CloudがないとAdobeのアプリケーションがアップデートできないので、困ると言えば困るので何とかする。

    再度、Creative Cloudをダウンロードしてきてインストールすると途中で止まる。

    一晩置いて再度インストールしてみたら、今度はインストールできた。しかし、起動できない。一旦インストールするとインストールプログラムが削除されるのは、成功するといいかもしれないけど、失敗すると再度ダウンロードになるから辛い。

    次に一旦Windows10の「設定」ー「アプリ」から一度アンインストールして、再度インストールしてみる。同じく起動できない。

    Googleさんに聞いてアドビのサポート情報を探し出す。

    Creative Cloud デスクトップアプリケーションが開かない | プログレスホイールが回り続ける

    アドビ

    Creative Cloud デスクトップアプリケーションのアンインストーラーを使用してアンインストールしてみろ、ということであった。素直にアンインストーラーを使って、Creative Cloudを削除する。続いてインストールする。

    今度はCreative Cloudが起動できた。サポートが言っていることに従ってやれば問題無かった。

  • CSSファイルのコンパイル前のSCSS(SASS)ファイルを欲しいと言っても、もらえなかった話し

    今、更新作業をしているサイトのデザインを変更のために、CSSファイルを変更しなければいけなくなりました。

    該当するCSSファイルを見てみると、2千行ほどあって、やけに綺麗にフォーマットされています。しかも、スタイルを定義している順番も階層の上位から下位にまとまっています。これは直接CSSファイルを追加しておらず、SCSS(SASS)ファイルからコンパイルされたCSSファイルではないかと見当をつけました。

    そこでお客さん経由でCSSファイルを作成した会社に、SCSSファイルを送ってほしいとお願いします。WebサーバーにはCSSファイルを置いてありましたが、SCSSファイルは見当たりません。

    しかし、開発会社の回答としてSCSSファイルは存在していない、ということでした。そんな馬鹿な・・・。

    おそらくSCSSファイルは成果物としては外に出したくないのでしょうね。お客さんから契約を持ち出して無理やり出してもらうことも考えましたが、それでもSCCSファイルは存在しないと押し通されそうです。SCCSファイルが存在することを証明するのは難しそうです。

    しかたないので、直接CSSファイルを修正していきます。大幅改修でこちらで修正されたCSSの箇所をSCSSに戻すことになったら、最小に開発した自分たちが困ると思うのですが。

    以前も同じようななことがありました。そのときはGIFファイルでした。見出し画像やメニュー項目に施したグラデーション背景に特別なフォントを指定した文字を変更しなければいけないときに、GIFの出力前の元のPhotoShopのPSDファイルを出してくれるようにお願いしたところ同様に断れました。

    PSDファイルを出してくれないデザイン会社は、今まで何社かあります。こちらは、自分のデザインを修正されないようにするということは若干理解できますが、デザインなしでフォントを貼り付けているだけのページ見出しくらいはいいじゃないかと思います。見出しが変更できなければ、新しいページを追加するたびに画像の作成だけに時間がかかるという問題になります。そのときはいちいちグラデーション背景と文字を分離するのも面倒なので、PhotoShopで画像を作るのは諦めて、テキストとCSSで実現できるように作成し直しました。フォントの指定は残念ながら無視して、同じようなサイズにしておきました。しかし、そのほうが、CSSのクラスと文字を指定するだけで見出しが表示できないので、この方法のほうが賢いです。

    そこでWebページでのデザイナーへのお願いです。

    デザインなしでそのままテキストの画像の貼り付けはやめてね

    どうしてもフォントのデザインが欲しいのなら、Webフォントを考えてね。そのとき、フォントのライセンス購入まで考えてね。Googeフォントでもいいからさ。

    それが嫌だったら、編集できるように元のPSDファイルを提供してね。まさかPhotoShopのレイヤーを使っていなかったら、背景の素材画像の提供と、フォントサイズとかフォント名とかのフォント情報を教えてね。そこまで言わないと何もやってくれないのは共同作業したくないのかよ、というのあるますけど。

    その会社はページの更新の仕事が回ってこないからそのようなことをしているかと思えば、ページ更新をやりたくないと言うので、私が代わりにやっているという流れがありますから、どうして出力前の元のファイルを出せないかというのは私にとって理解できません。私に意地悪しているのでしょうか??

    技術評論社
    ¥1,980 (2025/04/17 01:58時点 | Amazon調べ)

    追記(2021年2月8日)

    CSSファイルからSCSSファイルへの逆コンパイラってあるのだろうか? 探してみようと見つけたサイトは以下のサイトです。

    ここで紹介しているサイトでCSSをSCSSに変換してみたところ、正常にSCSSファイルに変換できました。

    出力されたSCCSをDreamweaverでCSSに変換したところ、うまくサイトに反映できました。

    それにしても、最近のDreamweaverのバージョンアップで、今までできなかったSCSSファイルの変換が正常にできるようになったようです。

  • さくらインターネットのサーバーかWordPressが原因かわからないけど、再利用ブロックが原因不明でGutenbergで呼び出しができなくなってしまっている話し

    以前でも再利用ブロックがGutenbergが呼び出しができなくなってしまったと書きましたが、再度この障害が出ています。自分のところだけの問題でしょうか? それとも、調子に乗って、たくさん再利用ブロックを作成してのが悪いのでしょうか?

    プラグインをすべて無効にしても、テーマを純粋のTwentyTwenty-Oneに戻してみても、何をやっても変わりありません。最近、Gutengergプラグインが何回か短期間に繰り返しアップデートになっていたので、それが原因かもしれません。

    あと怪しいのは、現在運用しているさくらインターネットのレンタルサーバーです。こちらは別のサーバーで、このWordpressのブログサイトを動かしてみて切り分けてみる必要があるかもしれません。他に500のサーバーエラーが出やすくなっているとか、たまに記事を公開すると

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    で失敗するとか、さくらインターネットのサーバーがおかしな挙動をしているので、さくらインターネットのサーバーから別のサーバーに移行しなければいけないかもです。さくらインターネットのサーバーでWordpressサイトを動かすと遅いという噂(本当かな?)がありますので、どこが原因なのかは、まだ未確定です。

    いずれにしても、さくらインターネッのサーバーから別のサーバーに移行するするのは大変で、できるならやりたくないのです。メールアドレスをレンタルサーバーに設定してしまっていますので、メール専用のサーバーに設定しておけばよかったと後悔するばかりです。

    そして気になるのは、Chromeのコンソールで見ると、以下のWordpressのREST APIのURLにアクセスしているようですが、

    https://www.5cho-me.com/wp-json/wp/v2/blocks?per_page=100&context=edit&_locale=user

    結果が、次のようなエラーになっていることでしょうか。

    {
      code: "rest_forbidden_context",
      message: "この投稿タイプの投稿を編集する権限がありません。",
      data: {
        status: 401
      }
    }

    権限と言われても、再利用ブロックの一覧表示以外は正常に動いていますので、何だかわかりません。Wordpressをやめて他のCMSに移行することも考えましたが、何せ数千の記事を作ってしまいましたので、ちょっとやそっとではWordpressから離れられません。

    今のところ、Gutenbergから再利用ブロックを選択して挿入できないので、

    <!-- wp:block {"ref":xxxxx} -->

    という再利用ブロックのHTMLコード(xxxxはブロックのID)を貼り付ける方法くらいしか思い付きません。でも、この方法はちょっと面倒です。Gutenbergが正常に対応してくれること望みます。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/05/07 13:25時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2021年2月6日)

    Gutenbergが昨日9.9.0に更新されたせいかはわかりませんが、たまに再利用ブロックの一覧を表示できるようになりました。たまに表示できるくらいですので、今も半分くらいは表示ができません。もし再利用ブロックの一覧が表示できない場合は、ブラウザの更新を実行すると表示してくれることがあります。それと

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    もたまに出ます。

    相変わらず、よくわかりません。

    続きはこちらから

    今回の不具合が一挙に解決した話しはこちらから。

  • さくらインターネットのVPSのサーバーを解約する準備をした話し

    もう8年近くさくらインターネットのVPSのサーバーを使っています。このブログのサーバーとか会社のサーバーとか、お客さんに公開するテストサーバーとか、情報を共有するためのWebサービスとか、諸々便利に使ってきました。

    ブログや会社のサーバーは、同じさくらインターネットのレンタルサーバーに移行しましたし、その他のテストサーバーとかWebサービスは、社内のQNAPで運用するように移行できたしで、さくらインターネットのVPSは利用しなくてよくなりました。とくに、さくらインターネットのVPSには不満があるわけでもなし、サーバーのアップデートが面倒であるくらいでした。

    今回、VPSのサーバーで動いていたApacheを停止してみて、特に問題ないことを確認します。ドメインのDNSの宛先がVPNのアドレスが残っていたので、こちらも設定を見直します。

    会社のドメインは、co.jpで取得していますが、いろいろとテストサーバーとかWebサービスでサイトを立ち上げる用に、別に同じ会社名で.comを取得しています。.comのドメインのWebサイトが404になっていたので、.co.jpのサイトにリライトするように.htaccessを設定しておきました。ドメインはさくらインターネットのレンタルサーバーにマルチドメインとして登録しておきます。日本語ドメインも持っていますが、こちらも404のNot Foundになっていましたので、こちらも.co.jpのサイトにrewriteするように.htaccessに書いておきます。.comと日本語ドメインとも、ずっと404になっていたのを見逃していました。これは私のミスです。

    加えて.com,日本語ドメインともHTTPSに対応しておきました。さくらインターネットのレンタルサーバーは、コントロールパネルでLet’s Encrypt のインストールができるのでとても簡単です。ほぼポチポチボタンを押していくだけで、SSLの設定が完了します。

    社内からはIPv6でつなぎに行きますので、社外からモバイルを使ってIPv4でも接続できるか確認して完了です。特に問題なく、.com,日本語ドメインとも正しく.co.jpのサイトに遷移できていることを確認できました。

    さくらインターネットのVPSは1年契約で7月まで契約がありますので、7月に忘れないように解約しておきましょう。また、いずれ再度VPSのサーバーを契約することがあるかもしれません。

    著:大竹 龍史, 著:山本 道子
    ¥2,950 (2025/05/02 10:49時点 | Amazon調べ)
    著:Piro, 編集:日経Linux
    ¥2,178 (2025/05/08 15:21時点 | Amazon調べ)
    著:三宅 英明, 著:大角 祐介
    ¥2,970 (2025/05/02 10:49時点 | Amazon調べ)

    続きはこちらから

  • アパートオーナーは入居者を選り好みするわけでもないけどさ、やはりこちらとしては入居者を選ばないといけいないという話し

    物件が古くなって家賃が下がってくると、いろいろな入居者の相談が不動産仲介業者からやってくる。

    今日、相談があったのは72歳の高齢で生活保護の男性で、お子さんが隣り駅に住んでいるそうだ。

    いろいろ聞いてみたら、行政からの支援が望めないということだし、万が一のときがあっても業者も面倒を見ることもしないそうだ。すなわち、トラブルが発生したらアパートオーナーに丸投げとなる。

    実は、別の物件で最近まで高齢者で生活保護の入居者がいたのだけど、庭で立ち小便とするとか、同じ入居者の後を付けてストーカー行為をはたらくとか暴言を吐くとか(おかげで入居者が退去してしまった)、昼夜逆転の生活で明け方洗濯し出すとか、しまいには警察の厄介のなるとか、ここ数年で奇行が目立ってきたので、その入居者の息子さんにお願いして退去してもらった。

    最初に入居した際には、行政の担当者や民生委員が支援をするという条件であったが、ここ数年支援が全くなくなって放っておかれてしまっていた。行政の担当者にお願いしても担当が替わったとかの理由で埒があかず、本人に直接お願いしも怒るばかりで話しも聞いてくれない。数々の奇行にオーナーとして頭を痛めていたが、最終手段として退去のお願いとなったのである。これ以上、同じアパートの入居者や近隣の人たちに迷惑をかけられると、他の入居者の退去でアパートの経営上厳しくなってくる。現にその物件は半分空いている。アパートというのは常に近隣の人たちや、同じ屋根の下の入居者と上手くやっていかないと、大きなトラブルに発展する。まして、火を出されるなんて最悪のことも考えなければいけなくなる。

    今回は引き取ってくれた息子さんがいたし、仲介した業者も骨を折って解決につなげてくれたので対応できたのでよかった。ただし、退去後の原状回復の費用は行政に問い合わせると、生活保護の人が借りている婆場合は出さないと言われてしまったので、全額費用をこちらが負担しなければいけないのはとても痛い。

    たまたま今回は退去してくれたことで解決したけど、これからもうまく行くかどうかもわからないし、今後もトラブルのリスクを負いたくないしで、今回の高齢で生活保護の入居の件はお断りすることにした。

    古い物件には、このような入居希望者を付けようとする業者や行政、はたまたNPOとかが出てくるが、しっかり退去する最後まで支援をしていただけるのであれば考えるけど、現状の誰も面倒を見てくれない状況だったら高齢者に部屋を貸すのは無理だと思う。貸す前に紹介してくる業者には、「もし、トラブルがあったら面倒見てくれるの?」と一応尋ねるけど、大抵は「うちでは難しい。」と言われてしまう。「それだったら、こちらも難しいよね。」となるのである。それで、この話しはお終いとなる。

    本当に弱い立場の人たちに住む場所を確保したいのであれば、大家に丸投げせずに最後まで皆さんで面倒見てくれと言いたい。「弱い立場の人だから家主は絶対に部屋を貸さなければいけない。」と関係のない言いっぱなしの無責任の人たちは言うかもしれないけど、ずっと部屋を貸すのだから高齢者がますます高齢になって今後うまく回っていくかなんか保証されない。もし、入居させるのであれば、もっと周りからも支援を継続して行って欲しいのである。途中で「知らないよ。」というのは無しなのである。

    まあ、部屋を貸したら何らかのトラブル(事件を起こして警察が張り込みを隣の空き部屋を貸さなければいけないとか、ロウソクの裸火でボヤを起こすとか、水を漏らして部屋中にカビを生えさせるとか、部屋の中で首を吊るとか、天井まで届くゴミ部屋にするとか。以上実際にあった話し)が発生するのは常であるので、そんな面倒を起こすくらいだったら、本当なら部屋なんて他人に貸したくないくらいなのである。しかし、これだとアパート経営としては本末転倒なのである。

    アパート経営なんてやめておけ

    アパートオーナーより
  • OCNサイトのおかしなUIに欺されるな、という話し

    支払いのクレジットカードを変更することになって、OCNモバイルのサイトで手続をする。

    OCNのサイトでは、認証が厳しくなっていて手続きの前に、SMSで認証番号を送って認証させる。

    SMSで認証させることはいいことだと思うけど、ここからが問題である。認証番号の入力項目の下にあるボタンを押すと、再度SMSを送るようになる。

    ボタンを見ると「再通知する」のボタンではないか!

    よく見ればいいけど、ここの位置のボタンは「ログインする」とか「確認する」とかのボタンではないか?

    正解は、もっと下のボタンである。画面サイズが狭いとスクロールしないと隠れてしまうところである。

    つまり、詐欺サイトもこんな場所にボタンを置けば、何も考えずにボタンを押してくれるのね。

    まあ、ボタンの内容をよく読まないのは問題だけど、これはあまりよろしくないUIの例だな。通知番号の再通知なんて、そうそうに行わないので、注意事項の中でのリンクでいいのに。

    ちなみに、OCNモバイルは家族3人で別々の契約をしているので、実は3回も再通知のボタンを押した私でした。そんなことをやるのはお前だけだよ、って聞こえそうでした。

  • アルカスイス互換というのに興味を持ってクイックリリースシューを購入したけど、ちょっと???だった話し

    アルカスイスの互換とはなんだ? でタイムセールで安くなっていたので、何事も知る経験ということでとりあえず買ってみた。1,000円しなかったのもので、つい買ってしまった。

    最初、スライドすれば外れると思っていたけど、ちょっと締め付けネジを緩めてもプレートの六角のネジが邪魔して外れなかった。これではクイックでも何でもないな。でものこのネジが邪魔してくれないと、不意にカメラが滑り落ちるということを防いでくれているのね。まあ、ネジを取ってしまえば、とりあえず解決するけど。

    しかし、カメラにプレートを付けておくと、このネジで正立できないのは仕方ないことなのかな? テーブルとか傷つけそうだし。それとスライドするのではなくて、斜めにはめるって感じなのかな。少しばかり、自分が想像しているのと違っているかも。

    あと、締め付けネジがとても堅い。でもグリスアップして緩くしてしまうと、こちらも不用意に外れてしまうということなのかな? 5回くらいねじらなくてはいけないのは面倒かもな。

    アルカスイス互換というのはこういうのもなのか、よくわかっていない。もっと高いものを買ってあげないと、そのよさは分からないものなのかな? でも互換でも何でもなくなるし。

    それと水準器は何のためにあるのかよくわからない。これはアルカスイスとは関係ないけど。

    以上、結果としては常用でカメラにプレートを付けておくものではないということがわかった。結局ねじ込みが必要なので普通の雲台と変わらないしな。良いところといえば、カメラ側の三脚ネジ穴辺りを傷つけないからいいくらいかな。

    追記(2021年3月9日)

    このアルカスイス互換のクイックリリースシューの三脚側は、ピークデザインのプレートが付くのでゴリラポットに付けている。カメラ側にピークデザインのプレートに付けておけば、リュックと三脚との脱着が簡単になる。

    Peak Design / ピークデザイン

    銀一株式会社 | 私達は、映像に関わる全ての人達に、最高の笑顔と感動を与えます。
  • 天井裏点検口の取り付けたら熱が出た話し

    コンセントの増設工事が終わったということで、天井裏にアクセスできる手段であった照明器具の取り付けと、その代わりの天井裏点検口を新しく取り付けた。これで照明器具を外さなくても天井裏にアクセスできる。

    天井裏点検口はただのアルミの枠である。今回、購入した天井裏点検口はこちら。付けよう付けようと思いつつ、買ってから1年以上経っている。

    ダイケン
    ¥1,336 (2024/01/06 23:31時点 | Amazon調べ)

    天井に穴を開けて、穴を開けた天井のボードを枠にはめる。取り付け方法は、YouTubeでも載っている。とても取り付けは簡単だった。

    天井裏の配線を切らないように天井を切り出す。今回はレシブロソーにボード用の刃を付けて切り出す。手鋸で切り出してもいいけど大変だろうな。切りカスが落ちないようにゴミ袋で受けていたけど無駄だった。床一面にボードの切りカスが散らばっていた。

    ゼット販売
    ¥652 (2024/01/06 23:30時点 | Amazon調べ)

    最後に切った後に天井のボードを落ちてこないようにテープで止めておくのだが、意外とボードが重くて見事にボードが落ちてしまった。これが唯一の失敗だった。ボードが割れなくてよかった。

    念のためにボードの支えとなる垂木を追加した。これでうまく取り付けができたみたい。

    その夜、どういう訳か下痢も伴う熱が出た。汗をたくさんかいてシャワーを浴びたりしたけど、天井のホコリにウイルスでも混じっていたのかな? 熱中症にでもかかったのかな?

    とても、辛い夜だった。いまも多少ふらつく。

  • IPv6 IPoEの再チャレンジした結果 ー 失敗した話し

    結局三連休はIPv6の設定で終わってしまった。IPv6の接続をやめると言いながら、気になることがあったので再チャレンジする。以下は、私の作業の記録であるので、真似をしてもうまくヤマハのRTX810でIPv6 IPoEで接続できないので注意してもらいたい。

    気になるのは、IPv6に設定したときにネームサーバーが正しく設定されているかである。RTX810の簡単設定ページにDNSの設定を任せていたので気にしていなかった。

    IPv4の2つのPPPoEのセッションで接続していると、以下の用にDNSが設定される。

    dns server pp 2
    dns server select 500001 pp 1 any . restrict pp 1
    dns server select 500002 pp 2 any . restrict pp 2
    dns private address spoof on

    今回初めて dns server select というのは知ったけど、pp1に繋がればpp1、pp2がつながればpp2のDHPCで配布されているDNSを使うと言ったことでしょうか?

    簡単設定ページで「新規プロバイダの追加」の「フレッツ 光ネクストにおけるインターネット(IPv6 IPoE)接続 」でIPv6 IPoEの設定を追加してあげると、DNSは「DNSサーバーアドレスを指定しない、またはプロバイダから自動取得 」に自動的に先駆されて、以下のように書き換えてくれる。

    dns service fallback on
    dns server dhcp lan2
    dns server select 500000 dhcp lan2 any .
    dns server select 500001 pp 1 any . restrict pp 1
    dns server select 500002 pp 2 any . restrict pp 2
    dns private address spoof on

    これだとIPv6のLAN2(WAN側)が接続できないとPP1,PP2のDNSを使いそうなので、 dns server select の設定を全部削除してしまう。これでWAN側で取得したIPv6のDNSを使うことになるはず。

    no dns server select 500000
    no dns server select 500001
    no dns server select 500002

    スマートフォンからIPv6で接続するできることを確認して、 IPv4, IPv6 のドメインで名前を引けることも確認し、さらにIPv4, IPv6のサイトを参照できることも確認してから、再び一晩放っておく。

    翌朝、スマートフォンで参照してみると、今まで同様にIPv4, IPv6のサイト とも接続できない。結果は失敗だった。しかしながら、PCでは正常にアクセスできている。

    上のDNSの設定は効果はなかったみたいだった。これは意味のなかった設定かもしれない。だってDNSの設定が間違えていたら、PCだってアクセスできないはず。

    IPv6の接続設定を戻した。もっと、IPv6やヤマハのRTX810について理解しなければいけないな。AndroidとWindows10のIPv6の実装の違いがあるのかな。

    続きはこちらから。

  • AWS ELBで常時SSL化したときの嵌まったことの話し

    お客さんのサイトを常時SSL化をしたときのメモ。というか嵌まったことをメモする。

    現在は、AWSのELB+EC2(Windows Server)で運用している。EC2はとりあえず一台で運用している。インスタンスが一つではロードバランスとか冗長化と関係ないが、でもEC2一台でもELBを入れておけば、サーバーのアップデートとか入れ替えが簡単だし(言い訳)。

    以上を常時SSL化を実施する。まずは、AWS Certificate Managerで証明書を発行する。認証が必要なのでDNSで認証する。AWS Certificate ManagerかかRoute 53に認証するSNAMEを追加してくれるので認証が簡単。

    HTTPでアクセスしたとき簡単にリダイレクトの設定をしてしまうとループするようなので、IISのReWriteモジュールにリダイレクトのルールを追加する。Web,configにAWSのサポートページにあったルールを追加するとエラーになる。これからがトラブルの始まり・・・。

    IISの設定から手作業でリダイレクトルールを追加する。参考にしたのは、こちらのページ。こちらでエラーもなくリダイレクトルールを追加できた。

    次にAWS ELBにHTTPSのリスナを追加する。そのときAWS Certificate Managerで作成した証明書を指定する。これで完了を思いきや、サイトにつながらなくなった。

    EC2のセキュリティグループを確認したり、Windows Serverのファイヤウォールを確認したりといろいろやってみたところダメ。これで作業終了かと思ったら、単にELBのセキュリティグループにHTTPSの設定がなかっただけだった。HTTPSを追加したらアクセスできた。

    しかし、www.付きのドメインだとEdgeやFirefoxでは証明書エラーとなる。www.なしのドメインだけだと正常。Chromeだとどちらでも保護されていると正常となる。

    これはAWS Certificate Managerで証明書を作ったときの失敗だった。www.無しのドメイン名だけで作成していた。www.付きでも大丈夫のように別名を指定して証明書を作ってあげるようにする。おかげで再度証明書を作り直す。

    AWS Certificate ManagerでDNS認証で、どういうわけかwww.付きのドメインの認証がやたら時間がかかった。作成に失敗したかと思って、もう一回証明書を作成し直してしまった。www.無しだとすぐに認証してくれたけど、無しだと1時間くらい認証に時間がかかった。これがAWSの仕様かどうかは不明。

    ELBのリスナーにHTTPSを追加する。このとき前の証明書の選択項目が残っていてリスナーの追加に失敗する。ELBから一旦別のAWSのサービスに行ってからELBに戻ると正常に追加できた。

    これで常時SSL化は完了。HTTPでアクセスしてもHTTPSにリダイレクトしてくれることも確認する。www.付きでも無しでも正常にアクセスしてくれることも確認する。

    途中、心が折れそうになったけど、無事に常時SSL化は完了。

    著:戸根 勤
    ¥2,376 (2025/04/30 09:39時点 | Amazon調べ)
    著:Gene
    ¥1,663 (2025/05/02 18:30時点 | Amazon調べ)