カテゴリー: FreeBSD

  • MariaDBのバージョンアップでハマった話

    MariaDBを、10.5系から11.8系にバージョンアップをしたのだが、このときの一連の作業でハマったことを書いておく。誰の役に立つのかはわからないけれど。

    なにが起きていたかというと、「10.5系のDB状態が正しい状態ではなかった」と「11.x の新しい仕様制限」の2つの組み合わせで、複合的なエラーが発生して解決できなかった。

    「10.5系のDB状態が正しい状態ではなかった」とは?

    • DBは正常終了させたはずだが、クラッシュした状態になっていた。
    • 以前に、10.5系にバージョンアップしたときに、DBのアップグレードをしたが、そのときから怪しげなログは出ていた。使えるからと放置していたのが、ここにきて問題が顕現した。

    「11.x の新しい仕様制限」は?

    • 11.x からクライアント接続時のSSL要求が厳格化された。mariadb-upgrade –skip-ssl で回避。
    • 10.5 時代の Redo ログ(ib_logfile0)が未消化(クラッシュ)のまま放置されていた。11.x系では、仕様上、直接復旧ができなかった。
    • 10.5 時代で使えていた設定が 11.x で完全撤廃された、というのもあるが、これにはハマっていないはず。

    いろいろと試したけれど、失敗したことなど。

    起動時のエラーが、.errファイルに記録されておらず、エラーログを探しまわることに。messagesにも記録がなく。データファイルの保存場所にあったファイルの更新日付からエラーが記載されたファイルを特定した。wsrep_recovery.failに記録されていた。

    一度、11.8を消して、10.5系のクラッシュの復旧ができる10.11系をインストールして、復旧を試みた。結局、MariaDBの起動時に復旧ができずに、クラッシュして、MariaDBは起動できなかった。

    Redoログファイル(ib_logfile*)をリネームして起動を試す。これは、「MariaDB 11.x(および 10.8 以降)ではセキュリティ・データ保護のための仕様が変更され、未修復(クラッシュ状態)のデータがある状態で ib_logfile0 を削除・退避してしまうと、起動を完全に拒否する仕組み」によって、成功せず。

    最終的にやったこと(成功したもの)

    結局、既存のデータベースファイルを使ったバージョンアップは諦めて、MariaDBを削除(アンインストール)して、データファイルを消して、新規に新しいバージョンのMariaDBをインストールして、初期化してMariaDBを起動させた。ちゃんと起動した後に、ダンプファイルから復元した。

    0. DBのバックアップ用にダンプファイルを取得(OSのバージョンアップ前にやっておく)

    1. MariaDBを削除(アンインストール)

    2. /var/db/mysql を退避・空にする

    3. 新しいバージョンのMariaDBをインストールする

    4. 「mariadb-install-db –user=mysql –datadir=/var/db/mysql」でDBの初期化(システムデータベースをインストール)

    5. MariaDBを起動する

    6. ダンプファイルからリストアする

    7. 復元したデータ構造を MariaDB 11.x 用に最適化(アップグレード検証)して再起動する。

    これで何とかなった。

    なんだかんだで、新しいバージョンをインストールしてダンプから戻すが一番楽かもしれない。

  • FreeBSD 14.2からFreeBSD 15.1へのバージョンアップはできた

    事前に調べた時に、FreeBSD 14.2 からFreeBSD 15.1のスキップでのバージョンアップはできるとのことだった。やっていると何が起こるのかわからないのが、アップデートの怖いところ。

    実際にFreeBSD 15.1へのバージョンアップを試したところ、OS部分については、問題なく、バージョン飛ばしでのバージョンアップができた。便利便利。

  • さくらインターネットのレンタルサーバで独自の404ページを指定する

    ウェブサイトの廃止に伴い、閉鎖のお知らせページを設定する。基本的に、エラーコード404のNot Foundばかりになるので、さくらのレンタルサーバで、404エラーページを独自に設定するようにしたメモ。

    さくらのレンタルサーバの管理画面では、404ページの設定はない。

    さくらのレンタルサーバでは、.htaccessを利用したウェブサーバの設定の上書きが可能。そのため、「.htaccess」を使って、404エラーのページを設定する。

    .htaccessの中身

    ErrorDocument 404 /404.html

    他に「.htaccess」で設定していることがなければ、この1行でよい。ファイルは作ってアップロードするか、管理画面のファイルマネージャーから作成して、書き込む。

    「404.html」は、設定したウェブサイトのフォルダのルートに置く。「/」でルートの階層を指定しているので。

  • FreeBSDでpkgをアップデートしたらMariaDBが起動しなくなった

    FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。

    原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。

    /usr/local/etc/mysql/conf.d/my.cnf

    このconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、1つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。

    いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す(リネームでOK)。server.cnfとclient.cnfの設定を確認して、MariaDB(mysqld_safe)を起動させる。

    ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。

    2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
    2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
    2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
    2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
    2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
    2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
    2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
    2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
    2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete
    
  • FreeBSD13.1にしたときにCertbotが消えていた

    FreeBSD13.1にアップグレードしたときに、pkgの更新も行ったためか、certbotがきえていた。Let’s Encryptの証明書が更新されているはずなのに、更新されず期限が切れたので、そこで気がついた。

    コマンドが消えて、エラーになった。(↓のコマンドが消えた)

    /usr/local/bin/certbot-3.8 renew

    pkgで探して、新しくインストール。

    pkg search certbot
    pkg install py39-certbot-1.27.0,1

    シンボリックリンクが作られていたので、そちらを利用して、証明書を更新した。そのあとに、Apacheを再起動。

    certbot renew
    httpd -k restart
  • お名前ドットコムのVPSの質が悪い

    またお名前ドットコムのVPSで、メンテナンスによりNICを変更された。固定IPアドレスはNICの設定となっているので、メンテナンスが終わってもネットワークには繋がらず。

    前もNICの割当が変更されてネットワークダウンしっぱなしになった。VPSはサーバ用のサービスなのだから、もっと気を使ってほしい。別にカスタムイメージを使っているわけでなく、標準インストールから使えるOSだったというのに。

    NICは、変更されて、10GのNICから、1GのNICに変更された。前のメンテナンスのときに10Gになったと思ったら、また1G接続に戻されたのだ。NICの接続速度は、10Gも使うわけはないのでよいのだが、そのためにNICごと変更するのは止めてほしいものだ。

  • 突然、Apache2.4の応答がなくなった

    休みで、のんびりと本をよんで勉強していたら、突然のアラート。調べてみると、サーバに対して、ping も飛ぶし、ssh接続もできた。死んでいるのは、Webサーバへのアクセスのみ。プロセスもみてみると、httpdはいる。ブラウザでは応答不能なので、正常に動作しておらず、ハングアップしたっぽい。(FreeBSD 13.1 release と Apache2.4 の組み合わせ)

    ↓ ps auxの結果

    root@ray:/var/log # ps aux | grep httpd
    root    925   0.0  0.9  48980  17712  -  Ss   25Jul22     1:44.07 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22306   0.0  1.6  63636  33864  -  S    10:59       0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22307   0.0  1.6  63700  34020  -  S    10:59       0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22308   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22309   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22310   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
    www   22311   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
    root  22314   0.0  0.1  12844   2032  0  S+   10:59       0:00.00 grep httpd

    「-DNOHTTPACCEPT」がhttpdの引数としてあるけれど、どうやらこれは関係ないっぽい。これがついていても、Apacheは動いているというページがあるので。

    「httpd -k restart」をやってみたが、なかなか応答が帰ってこず。応答が帰ってきたあとも、ブラウザではアクセスできず。

    完全にhttpdプロセスが止まっていないことも考慮して、「httpd -k stop」「httpd -k stop」を行ってみたが駄目だった。エラーは出ているけれど、httpd自体は起動できているので、とりあえず無視。

    root@ray:/var/log # httpd -k start
    [Mon Aug 15 10:59:51.520174 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
    [Mon Aug 15 10:59:51.520649 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
    [Mon Aug 15 10:59:51.520656 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filter
    [Mon Aug 15 10:59:51.520661 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filter

    もう一度、restartで再起動させてみたら、今度は正常にブラウザでアクセスできた。とりあえず、障害としては復旧したのでよし。

    http/httpsでの疎通が取れなくなった時間のエラーログも確認してみたが、エラーログは記録されていなかった。調査はしたけれど、結局、原因不明。

    自分のサーバなので、休みでよかった。しかし、休みで家にいるときに、この不可解な現象は・・・己の未熟さを顧みて、勉強を続けろってことだろうか。

  • FreeBSD 12.2 から 13.1 へメジャーバージョンアップ

    FreeBSDを、12.2 から 13.1 にメジャーバージョンアップをしたので、そのメモ。

    アップデートのコマンドと流れは下記。

    freebsd-update fetch
    freebsd-update install
    freebsd-update upgrade -r 13.1-RELEASE
    freebsd-update install
    shutdown -r now
    上がってこない。30分くらい。sshdは起動していたが、反応なし。ここからコンソールで作業した
    freebsd-update install
    (再度の実行を求められたのでもう一回)
    freebsd-update install
    shutdown -r now
    pkg-static upgrade -f

    FreeBSD 13.1の最初の “freebsd-update install” のあとに再起動したときに、OSは起動している状態になっていても、SSHで接続できない状態になった。確認してみると、sshdは起動していた。でも接続はできなかった。

    途中からコンソール接続して、アップデートを続けたので、リモートで作業する場合には要注意。PINGは飛んでいたので、OSは上がっているようにみえるのだけど、状態の確認ができなかった。

    参考

    https://www.freebsd.org/releases/13.1R/installation/#upgrade-binary

  • FreeBSDでpkgをアップデートしたらMariaDBが起動しなくなった

    FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。

    原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。

    /usr/local/etc/mysql/conf.d/my.cnf

    このconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、1つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。

    いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す(リネームでOK)。server.cnfとclient.cnfの設定を確認して、MariaDB(mysqld_safe)を起動させる。

    ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。

    2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
    2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
    2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
    2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
    2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
    2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
    2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
    2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
    2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete
  • FreeBSD 12.2 にアップデートした後にcertbotが使えなくなっていた。

    FreeBSD 12.2にアップデートした後に、Let’s Encryptの証明書更新に使っていたCertbot-3.7がなくなっていた。PKGを更新したときに多分クリーンされて消されたのだろうと推測。インストールされているPythonを調べたら、3.8になっていたこと、3.7のCertbotが見つからなかったので、certbot-3.8をインストールした。

    python3.8のCertbotを検索して、名前を調べて、インストール。

    ~ # pkg search py38-certbot
    ~ # pkg install py38-certbot-1.16.0,1

    その後、Crontabの設定も、`/usr/local/bin/certbot-3.7 renew` から `/usr/local/bin/certbot-3.8 renew` に変更した。

    それから、Let’s Encryptの証明書が保存されているディレクトリのパーミッションの問題で、Apacheからアクセスできなくなっていたので、パーミッションを変更した。これで、Apacheの再起動時にエラーもなくなった。

    やはり、細かい問題がいろいろと出てくる。