PC・コンピューター

PCやコンピュータ、サーバー、プログラミング等について書き留めています。

  • X(Twitter)タイムラインがWordPressに埋め込めない問題をChatGPTと徹底調査した結果


    はじめに

    このホームページにX(旧Twitter)のタイムラインを埋め込もうとしたところ、公式の埋め込みコードを使用してもタイムラインが表示されず、

    「Posts by ○○」というリンクだけが表示される

    という現象が発生しました。

    最初はWordPressの設定ミスを疑いましたが、原因が分からなかったため、ChatGPT(GPT-5.5)に調査を依頼し、一緒に原因を一つずつ切り分けていくことにしました。

    数時間にわたり、WordPress・Apache・HTML・JavaScript・ネットワーク・XのAPIまで順番に確認した結果、原因はX(旧Twitter)側の埋め込みサービスにある可能性が極めて高いという結論に至りました。

    同じ症状で困っている方の参考になればと思い、調査内容をまとめます。


    環境

    • WordPress 7.0.1
    • テーマ:Twenty Twenty-Five
    • サーバー:Ubuntu 24.04
    • Apache 2.4.64
    • PHP 8系
    • HTTPS(Let’s Encrypt)

    使用した埋め込みコード

    X公式(publish.x.com)が生成したコードをそのまま使用しました。

    <a class="twitter-timeline"
    href="https://x.com/kagaku_info?ref_src=twsrc%5Etfw">
    Posts by kagaku_info
    </a>
    
    <script async src="https://platform.x.com/widgets.js"
    charset="utf-8"></script>
    

    症状

    表示されるのは

    Posts by kagaku_info
    

    というリンクだけです。

    クリックするとXのプロフィールは正常に表示されますが、タイムラインは埋め込まれません。


    ChatGPTと一緒に原因を切り分ける

    ChatGPTからは

    「WordPressではなく、まず最小構成で試しましょう。」

    という提案がありました。

    そこで、WordPressを疑う前に、原因を一つずつ消していくことにしました。


    ① WordPressを疑う

    通常の段落ブロックではなく、

    カスタムHTMLブロック

    で公式コードを貼り付けました。

    結果

    改善せず。


    ② widgets.jsを確認

    Chrome DevTools の Network を確認すると

    https://platform.x.com/widgets.js
    

    は

    200 OK
    

    でした。

    つまりJavaScript自体は正常に読み込まれています。


    ③ JavaScriptエラーを確認

    Consoleには

    JQMIGRATE: Migrate is installed
    

    しか表示されません。

    JavaScriptエラーはありませんでした。


    ④ WordPressを完全に除外

    ChatGPTから

    「WordPressを使わないHTMLだけでも試しましょう。」

    と提案されたため、

    <!DOCTYPE html>
    <html lang="ja">
    <head>
    <meta charset="utf-8">
    <title>X Test</title>
    </head>
    <body>
    
    <a class="twitter-timeline"
    href="https://x.com/OpenAI">
    Posts by OpenAI
    </a>
    
    <script async src="https://platform.x.com/widgets.js"></script>
    
    </body>
    </html>
    

    という test.html を作成しました。

    結果は

    WordPressを使わなくても同じ症状でした。

    ここで

    WordPressは原因ではない

    ことが分かりました。


    ⑤ Apacheを疑う

    続いてChatGPTから

    「HTTPレスポンスヘッダーを確認しましょう。」

    という提案がありました。

    確認したところ

    • Content-Security-Policy
    • X-Frame-Options
    • Cross-Origin-Embedder-Policy

    などは一切設定されていません。

    Apache設定も確認しましたが、

    iframeをブロックする設定はありませんでした。

    ここで

    Apacheも原因ではない

    ことが分かりました。


    ⑥ ネットワークを変更

    さらに

    • スマホ4G/5G
    • スマホテザリング
    • VPNあり
    • VPNなし

    で確認しました。

    結果は

    すべて同じ。


    ⑦ OpenAI公式アカウントでも試す

    ChatGPTから

    「OpenAIなど別アカウントでも試してください。」

    という提案がありました。

    結果は

    OpenAIでも同じ症状。

    つまり

    アカウント固有の問題ではありませんでした。


    決定的な証拠

    ChatGPTから

    「Networkで syndication.twitter.com を確認してください。」

    と指示されました。

    すると

    https://syndication.twitter.com/srv/timeline-profile/...
    

    が

    429 Too Many Requests
    

    を返していました。

    つまり

    widgets.js
          ↓
    syndication.twitter.com
          ↓
    429
          ↓
    iframe生成失敗
    

    という流れになっていたのです。

    これが

    タイムラインが表示されない直接の原因

    でした。


    X Developer Communityでも確認

    ChatGPTに最新情報を調査してもらったところ、

    X Developer Communityには

    • widgets.jsは正常
    • timelineだけ表示されない
    • syndication.twitter.com が429
    • コードは変更していない

    という報告が複数ありました。

    つまり

    今回だけの現象ではありません。


    結論

    今回の調査では

    • WordPress
    • HTML
    • Apache
    • HTTPS
    • JavaScript
    • ネットワーク
    • スマートフォン
    • VPN

    まで一つずつ切り分けました。

    その結果、

    https://syndication.twitter.com/srv/timeline-profile/
    

    が

    429 Too Many Requests
    

    を返していることを確認しました。

    現時点では、

    WordPressやApacheではなく、X(旧Twitter)側の埋め込みサービスに原因がある可能性が極めて高い

    と判断しています。


    ChatGPTを使って感じたこと

    今回の調査では、ChatGPTは「答えを決めつける」のではなく、

    • 仮説を立てる
    • 一つずつ検証する
    • 結果に応じて仮説を修正する

    という形で、まるで一緒にデバッグを行うパートナーのように調査を進めることができました。

    途中で「WordPressではない」「Apacheでもない」といった結論も、実際の検証結果に基づいて修正しながら進められたため、最終的にはX側の埋め込みサービスが429を返しているという技術的な根拠までたどり着くことができました。

    AIは万能ではありませんが、人間が検証を行い、AIが次の切り分け手順を提案するという進め方は、トラブルシューティングにおいて非常に有効だと実感しました。


    とりあえず

    X(旧Twitter)とInstagram(インスタグラム)へのリンクはフッダーに付加してあります。

    また、埋め込みの試験をTESTで行っています。

    もし、Xのタイムラインの埋め込みがうまくいっている人がいらっしゃったらコメント欄からでも教えてください。

    投稿日:

    更新日:

  • リモート接続中にUbuntu 26.04へアップグレードしたら、RDPが切れた ― ChatGPTと一緒に復旧した顛末記 ―

    はじめに

    以前から使用していたUbuntuサーバーを、Ubuntu 26.04 LTSへアップグレードすることにしました。

    今回は、普段使用しているWindows PCからRDP(リモートデスクトップ)でUbuntuに接続した状態のまま、リリースアップグレードを実行しました。

    アップグレードは順調に進んでいるように見えましたが、途中で突然RDP接続が切断されました。

    「アップグレードによって再起動したのだろう」と考え、その後あらためてRDP接続を試みました。

    ところが、思ったように接続できません。

    結果的には、アップグレード自体はかなり進んでいたものの、多数のパッケージがまだ設定されていない状態になっていました。

    この後、ChatGPTに状況を相談しながら状態を一つずつ確認し、最終的にUbuntu 26.04.1 LTSを正常な状態まで復旧することができました。

    今回は、その顛末を記録しておきます。


    1.リモートデスクトップからUbuntuをアップグレード

    今回の環境は、

    • Ubuntu 25.10系からUbuntu 26.04 LTSへアップグレード
    • GNOMEデスクトップ環境
    • Wayland
    • GNOME Remote DesktopによるRDP接続
    • Windows PCからリモート操作

    という構成です。

    UbuntuはノートPCにインストールし、直接ノートPCのモニターとキーボードを使用するのではなく、Windows PCからRDPで接続して使用しています。

    そこで今回も、リモート接続した状態でUbuntuのリリースアップグレードを開始しました。


    2.アップグレード途中でRDPが切断

    アップグレード処理は大量のパッケージを更新するため、かなり時間がかかります。

    しばらくすると、突然RDP接続が切れました。

    ここで、

    「アップグレードが終了して再起動したのだろう」

    と考えてしまいました。

    しかし、これは少し早い判断でした。

    アップグレードでは、GNOME、GDM、Wayland、ネットワーク関連など、現在のリモートデスクトップ環境そのものに関係するパッケージも更新されます。

    そのため、アップグレード途中でGUIやRDPのセッションが切断されることがあります。

    問題は、

    「RDPが切れたこと」と「アップグレードが完了したこと」は同じではない

    ということでした。


    3.再接続できず、アップグレードの状態を確認

    RDP接続を再度試みましたが、思ったように接続できませんでした。

    そこでChatGPTに状況を説明し、まずシステムのパッケージ状態を確認することにしました。

    実行したのが、

    sudo dpkg --audit
    

    です。

    すると、

    展開されましたが、まだ設定されていません

    というパッケージが大量に表示されました。

    GNOME関連のパッケージをはじめ、デスクトップ環境を構成する多数のパッケージが未設定の状態になっていました。

    つまり、

    Ubuntuのアップグレードは途中まで進んでいたものの、完全には終了していなかった

    ことが分かりました。


    4.apt-get -f installで未設定パッケージを処理

    次にChatGPTの助言に従い、

    sudo apt-get -f install
    

    を実行しました。

    すると、大量のパッケージについて、

    ○○○ を設定しています ...
    

    という処理が始まりました。

    GNOME、GDM、polkit、ibus、Remmina、Nautilusなど、デスクトップ環境に関係するパッケージが次々と設定されていきます。

    また、カーネルについても、

    linux-image-7.0.0-30-generic
    

    が処理され、initramfsの生成やGRUBの更新も行われました。

    最終的には、未設定だったパッケージの処理が完了しました。


    5.dpkg --auditで状態を確認

    修復できたかどうかを確認するため、再度、

    sudo dpkg --audit
    

    を実行しました。

    今度は何も表示されません。

    これは、dpkgから見て未設定のパッケージが残っていないことを意味します。

    ひとまずパッケージ管理上は正常な状態に戻ったと判断しました。


    6.再起動

    その後、システムを再起動しました。

    sudo reboot
    

    再起動後、Ubuntuのバージョンを確認すると、

    uname -r
    

    の結果は、

    7.0.0-30-generic
    

    となっていました。

    さらに、

    lsb_release -a
    

    では、

    Distributor ID: Ubuntu
    Description:    Ubuntu 26.04.1 LTS
    Release:        26.04
    Codename:       resolute
    

    と表示されました。

    これで、Ubuntu 26.04.1 LTSへのアップグレードが正常に完了していることを確認できました。


    7.ところが、RDPにはもう一つ問題があった

    OSのアップグレードは完了しましたが、ここで別の問題が出てきました。

    今回の目的は、

    Ubuntu本体側でログインしていなくても、Windows PCからRDP接続してUbuntuにログインしたい

    というものです。

    ところが、通常のユーザーセッション用RDPでは、本体側ですでにUbuntuへログインしていないと、思ったように接続できませんでした。

    そこでChatGPTと一緒にGNOME Remote Desktopの状態を確認しました。

    grdctl status
    

    と、

    sudo grdctl --system status
    

    を比較すると、通常ユーザー用とsystem-wideのRDPが別々に存在していることが分かりました。


    8.system-wideのRDPを有効化

    そこで、system-wideのGNOME Remote Desktopを有効にしました。

    sudo grdctl --system rdp enable
    

    状態を確認すると、

    RDP:
        Status: enabled
        Port: 3389
    

    となりました。

    一方、通常ユーザー側のRDPについては、

    gsettings set org.gnome.desktop.remote-desktop.rdp enable false
    

    として無効化しました。

    これは、通常ユーザー用とsystem-wideのRDPが二重に動作して混乱することを避けるためです。


    9.ログイン前のRDP接続に成功

    ここまで設定したところ、期待していた動作が実現しました。

    Ubuntu本体ではログインしていない状態で、

    Windows PCからRDP接続。

    すると、リモート側からUbuntuへログインできました。

    つまり、

    Ubuntu本体
        ↓
    ログインしていない
        ↓
    Windows PCからRDP
        ↓
    Ubuntuのログイン
        ↓
    GNOMEデスクトップ
    

    という使い方が可能になりました。


    10.しかもリモート側は大画面で使用できた

    当初は、RDP接続すると本体画面が表示されたままになり、リモート側が「拡張デスクトップ」のようになってしまう問題もありました。

    現在の設定を確認すると、

    gsettings get org.gnome.desktop.remote-desktop.rdp screen-share-mode
    

    は、

    'extend'
    

    となっています。

    ところが、system-wideのRDPからログインした場合には、以前とは異なり、リモート側の大きな画面を使って通常のUbuntuデスクトップを操作できるようになりました。

    また、

    echo $XDG_SESSION_TYPE
    

    は、

    wayland
    
    echo $WAYLAND_DISPLAY
    

    は、

    wayland-0
    

    となっていました。

    結果として、現在はリモート側で快適にUbuntuを操作できています。


    11.今回分かったこと

    今回のトラブルを通して、いくつか重要なことが分かりました。

    ① RDPが切断されたからといって、アップグレードが終了したとは限らない

    アップグレード中は、GNOMEやGDMなどの更新によってGUIセッションが切断されることがあります。

    そのため、

    RDPが切れた → アップグレード完了

    と判断するのは危険です。


    ② dpkg --auditは非常に有効だった

    今回、アップグレードが正常に終了しているかどうかを確認するために、

    sudo dpkg --audit
    

    を使用しました。

    大量の未設定パッケージが表示されたことで、アップグレードが完全には終了していないことが分かりました。

    復旧後に再度実行して何も表示されないことを確認することで、パッケージ管理上の状態を確認できました。


    ③ apt-get -f installで未完了の処理を継続できた

    今回の復旧では、

    sudo apt-get -f install
    

    によって、未設定だった大量のパッケージが順次設定されました。

    結果として、GNOMEを含むデスクトップ環境を正常な状態まで戻すことができました。


    ④ リモート環境では「接続が切れること」を前提にした方がよい

    今回もっとも勉強になったのは、この点です。

    OSのアップグレードをRDPだけに頼って実行すると、アップグレードによってRDPそのものが切断される可能性があります。

    今後、同じような作業を行う場合には、SSHやtmuxなど、GUIとは独立した方法でアップグレードの状態を確認できるようにしておく方が安全だと思います。


    12.今回のまとめ

    今回のトラブルは、

    「リモートデスクトップでUbuntuをアップグレードしていたところ、途中でRDPが切断され、アップグレードが完全に終了していない状態になっていた」

    ことから始まりました。

    その後、

    dpkg --audit
          ↓
    未設定パッケージを確認
          ↓
    apt-get -f install
          ↓
    パッケージ設定を完了
          ↓
    dpkg --audit
          ↓
    問題なし
          ↓
    再起動
          ↓
    Ubuntu 26.04.1 LTSを確認
          ↓
    system-wide RDPを有効化
          ↓
    ログイン前のRDP接続に成功
    

    という手順で復旧しました。

    今回の復旧では、ChatGPTに実際のターミナル画面の結果を一つずつ提示しながら、原因を切り分けていきました。

    「何となく操作して直す」のではなく、コマンドの結果を確認しながら次の操作を決めることが、今回の復旧につながったと思います。

    最終的には、Ubuntu 26.04.1 LTSへのアップグレードを完了し、さらに、

    「本体側でログインしていなくても、Windows PCからRDP接続してUbuntuへログインし、大画面で操作する」

    という当初の目的も達成することができました。


    おわりに

    今回の経験から、リモート環境でOSの大きなアップグレードを行う場合には、

    「リモート接続が切れる可能性をあらかじめ想定しておく」

    ことが重要だと感じました。

    また、トラブルが発生したときには、いきなり設定を変更するのではなく、

    sudo dpkg --audit
    

    などで現在の状態を確認し、その結果をもとに復旧作業を進めることが大切です。

    今回はChatGPTにも協力してもらいながら、最終的に無事復旧することができました。

    同じようにリモート環境からUbuntuをアップグレードする方の参考になればと思い、今回の顛末を記録として残しておきます。

    投稿日:

    更新日:

  • ChatGPTと一緒にWebサイトをSSL化してみた

    先日、Ubuntu + Apache2 + WordPress環境で運用している当サイト「科学のつまみ食い(kagaku.info)」を、HTTPからHTTPSへ移行しました。

    最近ではHTTPS化は当たり前になっていますが、自宅サーバーで運用していると「そのうちやろう」と後回しにしがちです。私もまさにその一人でした。

    しかし、せっかく公開しているサイトですから、安全性や信頼性を高めるためにもSSL化しておきたいところです。

    そこで今回は、Let’s Encryptによる無料SSL証明書を利用し、サイト全体のHTTPS化に挑戦してみました。


    今回も頼りになったChatGPT

    実は少し前、WordPressをサブディレクトリで運用していた際に発生したトラブルを、ChatGPTの助けを借りながら解決したことがあります。

    ▶ 関連記事
    「WordPressサブディレクトリ運用時のトラブルと解決方法」

    今回のSSL化はトラブル対応というわけではありませんでしたが、一度その便利さを知ってしまうと、つい頼りたくなってしまいます。

    作業中に表示される警告メッセージや設定内容をChatGPTに確認しながら、

    • 現在の設定は正しいのか
    • 次に何を確認すべきか
    • エラーの原因はどこにありそうか

    を一つずつ整理し、問題を切り分けながら進めることができました。

    まるで隣に詳しいシステム管理者がいて相談しながら作業しているような感覚です。


    SSL化のために実施した作業

    今回実施した主な作業は以下のとおりです。

    1. Apacheの ServerName を設定し、AH00558警告を解消
    2. mod_ssl および mod_rewrite を有効化
    3. Certbot と Let’s Encrypt を導入
    4. DNS設定とApacheのVirtualHost構成を確認
    5. ルーターのポートフォワーディング設定(TCP 80/443)を確認
    6. Let’s EncryptからSSL証明書を取得
    7. Apacheへ証明書を自動設定
    8. HTTPからHTTPSへの自動リダイレクトを設定
    9. WordPressのURL設定をHTTPSへ変更
    10. Microsoft Edgeおよびスマートフォンから接続確認
    11. certbot renew --dry-run による自動更新テストを実施

    実際には、それぞれの設定項目が正しいか確認しながら進める必要があり、「SSL証明書を取得して終わり」というほど単純な作業ではありませんでした。

    特に、自宅サーバー環境ではDNS設定やルーター設定が関係するため、ネットワーク全体を見ながら確認する必要があります。


    結果は大成功

    無事に設定が完了し、現在のサイトは以下の状態で安定運用できています。

    • HTTPSによる暗号化通信
    • HTTPアクセス時のHTTPSへの自動転送
    • Let’s Encrypt証明書の自動更新

    ブラウザのアドレスバーにも鍵マークが表示されるようになり、サイトとしての安心感も大きく向上しました。

    利用者側から見れば小さな変化かもしれませんが、運営者としては達成感のある作業です。


    AIを活用したサーバー運用の可能性

    今回改めて感じたのは、ChatGPTがサーバー運用やシステム設定の強力なサポート役になるということです。

    もちろん最終的な判断や作業は自分で行う必要があります。しかし、

    • エラーメッセージの意味を調べる
    • 設定項目を確認する
    • トラブルの切り分けを行う
    • 作業手順を整理する

    といった場面では非常に心強い存在でした。

    以前のWordPressトラブル解決に続き、今回のSSL化もChatGPTの支援を受けながら無事完了できました。

    自宅サーバーを運用していると、思いもよらない問題に遭遇することがあります。しかし、そのたびに知識を積み重ねながら環境を改善していくのも、自宅サーバー運用の楽しみの一つではないでしょうか。

    今回のSSL化も、その良い経験となりました。もしこれからHTTPS化を検討している方がおられれば、本記事が少しでも参考になれば幸いです。

    投稿日:

    更新日:

  • WordPressサブディレクトリ運用時のトラブルと解決方法

    -ChatGTPの助けを借りて-


    自宅サーバー立ち上げで立ち上げたはずのサーバーがうまく動作しない。具体的には、WordPressインストールディレクトリを公開URLに表示させないようにしたところ、ディレクトリは公開されない設定には成功した。しかし、wordpressの標準でついてるブロックエディタ(Gutenberg)で編集した投稿内容が保存ができない。保存ボタンを押すと保存中のまま進行しない。

    という状況に陥ってしまいました。いくらやっても解決しないので、困ったときのChatGTPだのみです。ChatGPT(GPT-5.5)に調査を依頼し、一緒に原因を一つずつ切り分けていくことにしました。

    数時間にわたり、WordPress・Apache2の設定について順番に確認した結果、原因は、幾つかの設定ミスであったことが判りました。

    同じ症状で困っている方の参考になればと思い、ChatGTPと一緒に解決した方法をまとめました。

    構成

    • OS:Ubuntu 24
    • Webサーバー:Apache2
    • WordPress本体:/var/www/html/****
    • 公開URL:https://kagaku.info
    • WordPressアドレス:https://kagaku.info/****
    • サイトアドレス:https://kagaku.info

    発生した問題

    WordPressのインストールディレクトリを公開URLに表示しない設定後、次の現象が発生しました。

    • ブロックエディタ(Gutenberg)で保存すると「保存中」のまま終了しない
    • https://kagaku.info/wp-json/ が Not Found
    • パーマリンクを「基本」以外に設定すると記事が Not Found になる

    原因

    1. Apacheの mod_rewrite が無効だったため、WordPressのリライトルールが機能していなかった。
    2. 000-default.conf と wordpress.conf の2つのVirtualHostが同時に有効になっており、DocumentRoot が競合していた。
    3. 000-default.conf に AllowOverride All の設定がなく、.htaccess のリライトルールが適用されていなかった。

    解決方法

    1. mod_rewrite を有効化

    sudo a2enmod rewrite
    sudo systemctl restart apache2
    

    2. 000-default.conf を修正

    DocumentRoot を /var/www/html とし、次の設定を追加。

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    

    3. wordpress.conf を無効化

    sudo a2dissite wordpress.conf
    sudo systemctl reload apache2
    

    これにより、VirtualHostの競合を解消されました。

    動作確認

    以下を確認し、すべて正常に動作しました。

    • /wp-json/ がJSONを返す
    • パーマリンクが正常に表示される
    • ブロックエディタで保存できる
    • サイトが https://kagaku.info で正常に表示される

    現在の構成

    • 有効なVirtualHost:000-default.conf のみ
    • DocumentRoot:/var/www/html
    • WordPress本体:/var/www/html/****
    • ルートの index.php から wordpress/wp-blog-header.php を読み込む構成

    今回のトラブルは複数の要因が重なっていましたが、ChatGTPの力を借りて、一つずつ切り分けて原因を特定できたため、根本的な解決に至りました。今後同様の構成を構築する際にも役立つ手順になると思います。

    投稿日:

    更新日:

  • 自宅サーバー立ち上げ

    「科学のつまみ食い」のサーバーの歴史

    本自宅サーバを再構築しましたので、その経緯についてちょっと書いておきます。
    「「科学のつまみ食い」について」に本ホームページの歴史について記載してありますが、時系列のみ繰り返すと、以下の表のような変遷をたどってきました。

    1999年5月外部サーバー(nifty)にて「科学のつまみ食い」を開始
    2002年7月独自ドメインkagaku.infoを取得
    2002年8月自宅サーバー構築:DELL Latitude XP / VineLinux / HTMLエディタ
    外部サーバーから自宅サーバーに移行
    本ドメイン https://kagaku.info/で運用開始 
    2005年7月自宅サーバー入替:同機種/VineLinux/ HomePageBuilder+SiteMan
    2014年9月自宅サーバー入替:Loox P70XN / Vine Linux6.3 / WordPress
    リニューアル移設
    2017年5月自宅サーバー入替:Let’sNote CF-S8 / Vine Linux6.5 / WordPress
    2026年7月自宅サーバー入替:HP ProBook 430 G3 / ubuntu 24 / WordPress
    リニューアル移設

    ここでは今回 2026年の最新の自宅サーバーの入れ替えについて書きとどめておきます。

    もともとWindows11で運用していたHP ProBook 430 G3ですがWindows11ではかなり重くなってきたので、「科学のつまみ食い」で運用することとしました。これまでサーバーとして運用してきたLet’sNote CF-S8 とスペックを比較すると以下のようになります。

    項目Let’s note CF-S8HP ProBook 430 G3
    発売時期2009年2015年
    CPUCore 2 Duo P8700 2.53GHz
    (2コア)
    Core i3-6100U 2.3GHz
    (最大2.8GHz、2コア4スレッド)
    世代差Core 2世代 第6世代 Skylake
    メモリ4GB DDR28GB DDR3L
    ストレージHDDSSD
    画面サイズ12.1インチ WXGA 13.3インチ HD
    解像度1280×800 1366×768
    グラフィックスIntel GM45内蔵GPU Intel HD Graphics 520

    という感じで大幅にスペックアップしています。まぁ、HP ProBook 430 G3も10年前の機種なので最近の機種から見ると劣りますが、サーバーとして使うのには十分だと思ってます。



    サーバー構築

    ということで、ここからサーバー構築のメモです。

    ubuntuのインストール

    まず、準備したHP ProBook 430 G3にubuntuのインストールです。

    Ubuntuを入手する | Ubuntu | Ubuntu から最新版のUbuntuを ダウンロードし、起動メディアをUSB等で作成してインストールします。
    参考になるホームページがネットにあふれているので問題ないと思います。

    ユーザーやルートの設定など一通りします。


    リモートデスクトップ(RDT)

    次に、いちいちノートPCのHP ProBook 430 G3を広げてubuntu等サーバーのメンテをするのは面倒なので、通常のPCからリモートデスクトップ(RDT)で接続できるようにします。以下のホームページが参考になります。

    Ubuntu 24.04 LTSで新しい標準RDP接続を試してみる – treedown’s Report
    第819回 Ubuntu 24.04 LTSのリモートデスクトップを深掘りする | gihyo.jp

    RDTでubuntuサーバーに接続してみると、画面サイズが接続元の画面サイズまで大きくならない。最大でもHP ProBook 430 G3のスペックの1366×768 です。これは寂しい。デスクトップPCでは4Kディスプレイを使用しているので、そこまで画面を広げたい。ということで、以下のホームページを参考にして設定しました。

    Hyper-VでUbuntuを動かす際の解像度設定 #ubuntu20.04 – Qiita
    Hyper-Vで動いているUbuntuの解像度設定|たらかた


    サスペンドさせたくない

    さて、RDTが可能になったら、ノートPCを開く必要はありません。そこで、ノートPCの蓋を閉じてもサスペンドしないようにします。こちらは、以下のホームページを参考にしました。

    【Ubuntu】蓋を閉じてもノートPCをスリープにしない方法 | 機械学習ナビ

    これでサーバーとしての運用準備は整いました。



    WordPress環境の構築

    では次にWordpress環境の構築です。

    WordPressは、投稿、ページ、コメント、カテゴリ、タグ、カスタムフィールド、ユーザー、その他のWordPress設定など、多くの情報をMySQL等のデータベースに保存し、そのデータベースでデータを保存、検索、取得、更新、削除などの操作をPHPからのSQLクエリを通じて実行し、Apache2等のWebサーバーソフトウェアを通してホームページとして公開します。

    従って、これら、WordPress、MySQL、PHP、Apache2等をインストールして設定する必要があります。ここでは、それらを含めて順に概要を説明していきます。

    主に以下のホームページを参考にしました。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita
    Ubuntu 22.04 LTS に WordPress 7.4 をインストール #mariadb – Qiita
    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc
    Ubuntu で WordPress のインストール|金子邦彦研究室
    自宅サーバでWordPressを動かそう。インストール | じじぃの引出し

    探せばまだまだ出てきますので、各自わかりやすいのを参考にするのが良いと思います。


    Apache2のインストール

    まず、Apache2をインストールします。

    Apache2のインストール手順 #Ubuntu – Qiita


    PHPのインストール

    次にPHPをインストールします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    次にphpの設定内容を確認するために以下のページを参考にphp.iniを編集しphpinfo.phpを作成します。

    php.ini完全ガイド|設定ファイルの場所から編集方法まで徹底解説 | ちょげぶろぐ
    PHP | php.iniファイルの作成と初期設定

    一応、このサーバーでは、以下のように設定しています。

    memory_limit = 128M    → memory_limit = 256M
    post_max_size = 8M    → post_max_size = 64M
    upload_max_filesize = 2M → upload_max_filesize = 32M
    allow_url_fopen = On    → allow_url_fopen = Off
                  → date.timezone = “Asia/Tokyo”


    MySQLのインストール

    ではデータベースの以下のホームページを参考に
    MySQLをインストールします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    次に以下を参考に
    mysql_secure_installationコマンドを利用してMySQLの初期設定を行います。

    MySQL 8.0 インストール後に必ず設定する 3の項目 | りんか ネット

    初期設定が終わったら、以下を参考に
    WordPress用のデータベースとユーザーを作成します。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita

    これで、MySQLのインストールと設定が終わりました。


    WordPressのインストール

    さて、ようやくWordPressのインストールです。
    WordPressのインストール方法は、冒頭に示した以下のホームページが参考になると思いますので再掲しておきます。。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita
    Ubuntu 22.04 LTS に WordPress 7.4 をインストール #mariadb – Qiita
    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc
    Ubuntu で WordPress のインストール|金子邦彦研究室
    自宅サーバでWordPressを動かそう。インストール | じじぃの引出し

    ここでちょっと…
    WordPressをインストールしたディレクトリにはwww-dataというユーザー名とグループ名のディレクトリやファイルができます。で、これ何?って思って調べてみると以下の通りでした。

    www-data とは何か? – tech-hint

    で次に以下のホームページを参考にして
    WordPressの初期設定をします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    これで一応、設定完了


    サブディレクトリをURLに表示しない

    WordPressをhtml/以下のサブディレクトリ(例えば、****)に設置すると、そのサブディレクトリ名がURL上に表示されます。例えば、この「科学のつまみ食い」だと https://kagaku.info/****/ 等と表示されてしまいます。これはちょっといただけないので、以下のホームページを参考に https://kagaku.info/ と表示させます。

    【WordPress】サブディレクトリをURLに表示しない方法

    さてこれで出来上がり!!

    参考になったでしょうか?

    で、実はここで問題が発生しました。
    ChatGTPの力を借りて、解決しました。
    解決方法は、WordPressサブディレクトリ運用時のトラブルと解決方法を参考にしてください。



    先人たちの多くの記録が今回のサーバー立ち上げに大変役に立ちました。ここで引用した多くのホームページを参考にさせていただきました。ありがとうございました。

    投稿日:

    更新日: