変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

[podman]AlmaLinux:lastest

1.起動しないコンテナ?

# podman search almalinux:latest
NAME                                   DESCRIPTION
docker.io/almalinux/almalinux          DEPRECATION NOTICE: This image is deprecated...
docker.io/library/almalinux            The official build of AlmaLinux OS.
docker.io/almalinux/9-base             AlmaLinux 9 Base container image
docker.io/almalinux/8-base             AlmaLinux OS 8 official base image
docker.io/almalinux/9-minimal          AlmaLinux 9 minimal container image
docker.io/almalinux/9-init             AlmaLinux 9 Init container image
docker.io/almalinux/9-micro            AlmaLinux 9 Micro container image

docker.io/library/almalinuxが良さそうな気がしたので、イメージをダウンロードして以前やった様に・・・

# podman pull docker.io/library/almalinux:latest
# podman run -d \
    --name almalinux9 \
    almalinux:latest    ※The official build of AlmaLinux OS.

とやってみると、コンテナが終了してて【起動】ボタンを押しても起動しない。

ググってみると、

# podman run -d \
    --name almalinux9 \
    -it \               ※ --interactive(-i) + --tty(-t) => -it
    almalinux:latest    ※The official build of AlmaLinux OS.

と–interactive(-i)「対話式プロセス」と–tty(-t)「疑似端末割当」のオプションを付けると起動してくれる。Debian系では無くても起動してたけどRedHat系では付けておいた方が良さそう。

2.アタッチして抜けるとコンテナが【終了】※どのコンテナでも

アタッチしてバージョンを確認してexitするとコンテナが止まってしまうので

【Ctrl】+【p】と【Ctrl】+【q】を続けて押して、そっと抜ける方がいい。

# podman attach almalinux9
# cat /etc/redhat-release 
AlmaLinux release 9.5 (Teal Serval)
※Ctrl-p & Ctrl-q で抜けるとコンテナは「実行中」のままになる

3.とりあえず中を覗きたいだけの場合

# podman run -a \
    --name almalinux9a \
    -it \
    --rm \
    docker.io/almalinux/9-minimal
✔ docker.io/library/almalinux9a:latest
Trying to pull docker.io/library/almalinux9a:latest...
Error: initializing source docker://almalinux9a:latest: reading manifest latest in docker.io/library/almalinux9a: requested access to the resource is denied

と終了後にコンテナを削除するオプションを付けるといいかもとやってみると毎回イメージをダウンロードで失敗するので、 -aは現状使えない。ググってみると-aのオプションを説明してる記事も無かった。

# podman run -d \
    --name almalinux9a \
    -it \
    --rm \
    almalinux:latest
# podman attach almalinux9a
# exit

とちょっと面倒になってる。

–rmについては1行コマンドを実行する分にはそれなりに使える

$ podman run --rm almalinux:latest ls -alF /etc
total 884
drwxr-xr-x 46 root root   4096 Mar  7 07:53 ./
dr-xr-xr-x  1 root root     17 Apr  1 23:00 ../
-rw-------  1 root root      0 Mar  7 07:53 .pwd.lock
-rw-r--r--  1 root root     14 Mar  7 07:53 BUILDTIME
-rw-r--r--  1 root root     94 Jan 31  2022 GREP_COLORS
drwxr-xr-x  5 root root     51 Mar  7 07:52 X11/
・・・

でも非同期でコマンドを実行してるらしく、シェルは期待したようには動かない。

# podman run --rm almalinux:latest /bin/bash
# ※即終了&コンテナ削除


[WordPress]podmanでサイトを作る

cockpitのpodmanアプリケーションを使うと毎回画面でチョコマカと手入力が必要なので今回はpodmanをコマンドラインから使ってサイトを作ってみる。

1.podの作成

podを作る際に、ホストのポートからコンテナのポートへの転送も指定する。

ついでに外部へのポート開放もする。

# podman pod create -p 20080:80 -p 20443:443 -p 20090:8090 --name wordpress_pod
cee956541b051b84e15e7ac5e347a6aeb572b0aef16084954818e725f038cb1b

# firewall-cmd --add-port=20080/tcp --permanent ※永続的解放
# firewall-cmd --add-port=20443/tcp --permanent ※永続的解放
# firewall-cmd --add-port=20090/tcp --permanent ※永続的解放 phpMyAdmin用
# firewall-cmd --reload
# firewall-cmd --list-all ※設定を確認

※2025/4/1 phpMyAdminの設定を追記

2.イメージのダウンロード

mariaDBとwordpressのイメージをダウンロードする

# podman pull docker.io/mariadb:latest
Trying to pull docker.io/library/mariadb:latest...
Getting image source signatures
Copying blob 597f7afe50fe done   | 
Copying blob 5a7813e071bf done   | 
Copying blob 5db80086e4da done   | 
Copying blob bdecd990c29c done   | 
Copying blob 901fe9394c00 done   | 
Copying blob 43eb19e1b102 done   | 
Copying blob e1dede558384 done   | 
Copying blob 5c3a22df929b done   | 
Copying config a914eff5d2 done   | 
Writing manifest to image destination
a914eff5d2eb4c650a4e787e453d52a4ffba977632bd624cc6e63d0c9c4c2d65

# podman pull docker.io/wordpress:latest
Trying to pull docker.io/library/wordpress:latest...
Getting image source signatures
Copying blob e4ca7ebe0914 done   | 
Copying blob 6e909acdb790 done   | 
Copying blob dacb60b59038 done   | 
Copying blob 5db2c4b6137b done   | 
Copying blob 64450047668b done   | 
Copying blob 4d6386e035f7 done   | 
Copying blob 3dc5d9089396 done   | 
Copying blob 1778f52baa09 done   | 
Copying blob a5d9cb1c80ec done   | 
Copying blob b116c8459f57 done   | 
Copying blob 8f8ddda3587a done   | 
Copying blob f432ea27fc70 done   | 
Copying blob 6a5a37a900f3 done   | 
Copying blob 4f4fb700ef54 done   | 
Copying blob 57c6ea19af98 done   | 
Copying blob ae777a0ca433 done   | 
Copying blob 5f19650adea9 done   | 
Copying blob 177323f85a94 done   | 
Copying blob fe638a1d1db7 done   | 
Copying blob f4abcace8187 done   | 
Copying blob 729bf49a9314 done   | 
Copying blob cac8b814902b done   | 
Copying config 52bb3e7315 done   | 
Writing manifest to image destination
52bb3e73152ae8a92ef5a7d0589d923aa3c46538c8494b644b8cf2f5ceba2d37

# podman pull docker.io/phpmyadmin:latest
Trying to pull docker.io/library/phpmyadmin:latest...
Getting image source signatures
Copying blob 6e909acdb790 skipped: already exists  
Copying blob 64450047668b skipped: already exists  
Copying blob 4d6386e035f7 skipped: already exists  
Copying blob e4ca7ebe0914 skipped: already exists  
Copying blob dacb60b59038 skipped: already exists  
Copying blob a5d9cb1c80ec skipped: already exists  
Copying blob 1778f52baa09 skipped: already exists  
Copying blob 3dc5d9089396 skipped: already exists  
Copying blob b116c8459f57 skipped: already exists  
Copying blob 8f8ddda3587a skipped: already exists  
Copying blob 6a5a37a900f3 skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob f432ea27fc70 skipped: already exists  
Copying blob 2356864ac4b9 done   | 
Copying blob 28fa232eddfc done   | 
Copying blob a084403b2fe2 done   | 
Copying blob 69286ddc9ea5 done   | 
Copying blob 21d6bc6af9fd done   | 
Copying blob 5db2c4b6137b skipped: already exists  
Copying blob 5fb8db322bbb done   | 
Copying config 052506f2de done   | 
Writing manifest to image destination
052506f2de4d5532efb7c1b24b9a4311d6b5ccef006e344449f8fe633d3bbacc

※2025/4/1 phpMyAdminの設定を追記

podman diff イメージ名 で1つ1つファイル構成を見るものいいけど、

podman inspect イメージ名 の方が楽な気がする。

# podman inspect mariadb:latest
# podman inspect wordpress:latest 
# podman inspect phpmyadmin:latest

※2025/4/1 phpMyAdminの設定を追記

3.コンテナの設定

https://hub.docker.com/_/mariadb でmariadbコンテナで設定する環境変数等を調べ、コンテナを作成し実行する。

"Volumes": {
    "/var/lib/mysql": {}
},
# podman run -d \
    --pod wordpress_pod \
    --name mariadb \
    --restart=unless-stopped \
    -e MARIADB_RANDOM_ROOT_PASSWORD=1 \
    -e MARIADB_USER={WordPressで使うユーザ名} \
    -e MARIADB_PASSWORD={WordPressで使うユーザのパスワード} \
    -e MARIADB_DATABASE={WordPressで使うデータベース名} \
    -e TZ=Asia/Tokyo \
    -v {データベースを保存する作成済みの空ディレクトリィ}:/var/lib/mysql \
    wordpress:latest

とりあえずwordpressイメージにcerbotをインストしたイメージを作成 ※追記 2025/4/1

FROM wordpress:latest
RUN apt update -y
RUN apt install -y certbot python3-certbot-apache
RUN apt clean                     ※キャッシュ消去
RUN rm -rf /var/lib/apt/lists/*   ※ログ消去
podman build -t wordpress_certbot .

https://hub.docker.com/_/wordpress でwordpressコンテナで設定する環境変数等を調べ、コンテナを作成し実行する

"WorkingDir": "/var/www/html",
# podman run -d \
    --pod wordpress_pod \
    --name wordpress \
    --restart=unless-stopped \
    -e WORDPRESS_DB_NAME={WordPressで使うデータベース名} \
    -e WORDPRESS_DB_USER={WordPressで使うユーザ名} \
    -e WORDPRESS_DB_PASSWORD={WordPressで使うユーザのパスワード} \
    -e WORDPRESS_DB_HOST={mariaDBのコンテナ名} \
    -v {wordpressのhtmlを保存する作成済みの空ディレクトリィ}:/var/www/html  \
    wordpress_certbot 

ブラウザで、http://{podmanをインストしたホストのIPアドレス}:20080 を開くと

が見れる(ハズ。

さらに必須情報を行い、

【WordPressをインストール】ボタンを押し

となれば、後はログインでジャンプして

先のユーザ名とパスワードを入力して【ログイン】ボタンを押すと

が見れる(ハズ

cockpit-podmanで出来上がりを見ると

※既にpod終了済

ここでworspress_podの右端の縦点なメニューで起動とか終了で簡単に運用。

バックアップするディレクトリィは、上の -v オプションで指定したディレクトリィの2つ。

-v {データベースを保存する作成済みの空ディレクトリィ}:   ※コンテナ上のパスは/var/lib/mysql
-v {wordpressのhtmlを保存する作成済みの空ディレクトリィ}: ※コンテナ上のパスは/var/www/html

ps.2025/3/31

SSLについて

コンテナのOSを調べたら

# podman exec -ti wordpress /bin/bash
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"

Debian 12らしい、ググってみると

# apt install -y certbot python3-certbot-apache

でうまくいくらしいのでwordpress_cerbotイメージを作った。

コンテナを作る度にcerbotのインストを繰り返さずに済むらしい。

この時点ではまだcerbotの初期設定は行っていないので、WANから接続できる状況にした上で初期設定を行い、

# podman exec -ti wordpress /bin/bash
# certbot run

成功したら、いつもの様にコンテナを再起動して本当に大丈夫なのか?(要確認

ps.2025/4/1

phpMyAdminを忘れていた。残念だが、wordpressのaptリポジトリィを調べてみると

  • cat /etc/apt/sources.list.d/debian.sources
    • http://snapshot.debian.org/archive/debian/
    • http://snapshot.debian.org/archive/debian-security/

しかないので、wordpressイメージにphpMyAdmin付きのDockerfileでbuildしてもエラってしまうので

# podman pull docker.io/phpmyadmin:latest
Trying to pull docker.io/library/phpmyadmin:latest...
Getting image source signatures
Copying blob 6e909acdb790 skipped: already exists  
Copying blob 64450047668b skipped: already exists  
Copying blob 4d6386e035f7 skipped: already exists  
Copying blob e4ca7ebe0914 skipped: already exists  
Copying blob dacb60b59038 skipped: already exists  
Copying blob a5d9cb1c80ec skipped: already exists  
Copying blob 1778f52baa09 skipped: already exists  
Copying blob 3dc5d9089396 skipped: already exists  
Copying blob b116c8459f57 skipped: already exists  
Copying blob 8f8ddda3587a skipped: already exists  
Copying blob 6a5a37a900f3 skipped: already exists  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob f432ea27fc70 skipped: already exists  
Copying blob 2356864ac4b9 done   | 
Copying blob 28fa232eddfc done   | 
Copying blob a084403b2fe2 done   | 
Copying blob 69286ddc9ea5 done   | 
Copying blob 21d6bc6af9fd done   | 
Copying blob 5db2c4b6137b skipped: already exists  
Copying blob 5fb8db322bbb done   | 
Copying config 052506f2de done   | 
Writing manifest to image destination
052506f2de4d5532efb7c1b24b9a4311d6b5ccef006e344449f8fe633d3bbacc
# podman run -d \
    --pod ssiscirine_pod \
    --name phpmyadmin \
    --restart=unless-stopped \
    -e PMA_ARBITRARY=1 \
    -e PMA_HOSTS={mariadbコンテナ名} \
    -e PMA_USER={root} \
    -e PMA_PASSWORD={rootのパスワード} \ ※mariadbでrootパスワードをランダム生成した場合は毎回ログからコピペになる。
    -e APACHE_PORT=8090 \
    -v {phpMyAdminのsessionsを保存する作成済みの空ディレクトリィ}:/sessions:rw \
    phpmyadmin:latest
3dbb9be21d3b146a2430079b3e2158c5b267a751062198d400dc6594cb3dd128

※他のボリュームオプションに指定したディレクトリィはオーナが書き換わるが、このsessionsのボリュームオプションを指定した場合のディレクトリのオーナが書き換わらないので最初は888にしないとエラる。セッションファイルが作られた後は755に戻しても大丈夫っぽい。

※APACHE_PORTを付け忘れるとコンテナ同士で80ポートがコンフリクトしてしまう。

厄介なのがpodのポート変換を後付けする方法が見つからなかったので全部再生成しないといけない。

# {podの作成}
# {ポート開放}
# {mariadbコンテナの作成}     ※ログにrootのパスワード生成が載ってるか要チェック
# {wordpressコンテナの作成}
# {phpmyadminコンテナの作成} ※rootのパスワードを修正が必要な場合もある

それは嫌な場合は、wordpressコンテナからphpmyadminコンテナに転送するといいかもしれない。

# a2enmod proxy
# a2enmod proxy_http
# service apache2 restart
ProxyRequests Off
ProxyPass /phpMyAdmin/ http://phpMyAdmin:8090
ProxyPassReverse /phpMyAdmin/ http://phpMyAdmin:8090

でもLAN内でしか使わないからpodから作りなおすけどね。(笑

となると

残念ながらイメージが2.43GBに増えコンテナも315MBに増えた。



[WordPress]cockpit-podmanでサイトを作る

まず、色々ぐぐってみると

podmanのCLIで組んでる方が多く、

cockpit-podmanアプリでwordpressサーバを作ってるとこは少なかった。

しかもコンテナのイメージのバージョンの差異のせいか?

環境変数の設定が微妙にうまくいかなかったりするので、

ココの記事の内容も当てにできないと思います。

地道にDockerの各コンテナイメージの説明をよく読んだ方が良さそうです。

そんな訳で・・・

  • データベースはMariaDBが良いかな
  • WordPress自体がPHPで出来ている

ということで2つのイメージで組み立てることにする。

  1. Podを作る
    • コンテナ同士の通信をしやすくする為
      • IPアドレスを共有するのでコンテナ毎にポート開放する手間が不要
      • Pod内のコンテナ同士の識別はIPアドレスではなくコンテナ名を使用
      • pod起動終了で中のコンテナが一斉に起動終了するのは便利
      • 最重要:pod作成時に必要なポート開放をする必要がある
        • 最初はpod無しで試した方が絶対安全(だと思う
          • ポート開放等の設定ミスや漏れがあれば全部やり直し
            • Configureファイルを作り
              • podmamのコマンドでエラー&リトライが近道
  2. MariaDBのコンテナを作る
    • 他のDBでもいいけどAlmaLinuxにリポジトリィにある
    • 初期設定は環境変数設定のみ
      • コンテナのコンソールでシェルが動いてない
        • podman exec mysql で設定不可
  3. WordPressのコンテナを作る
    • 初期設定は環境変数設定のみ
      • コンテナのコンソールでシェルが動いてない
        • WordPressの展開も困難
        • PHPインストとini調整
        • Apache設定不可

の手順で作成する。

1.Podを作る

cockpitのPodmanアプリのコンテナーの右端の【Podの作成】ボタンからこんな風に作る。

とりあえずホスト側でポートマッピングしたホストポートを解放。

# firewall-cmd --add-port=20080/tcp --permanent
# firewall-cmd --add-port=20443/tcp --permanent
# firewall-cmd --reload

2.MariaDBのコンテナを作る

イメージのとこの【新規イメージのダウンロード】ボタンでイメージをダウンロードしておく。

podのとこの【podでのコンテナーの作成】ボタンで・・・

wordpressコンテナからmariadbコンテナ名で接続先を指定するので、コンテナ名は「mariadb」とか判りやすいものにしておく。

DockerのMariaDBのページに環境変数の設定がある。

ここで

  1. MARIADB_ROOT_PASSWORD={ルートのパスワード}
  2. MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1
  3. MARIADB_RANDOM_ROOT_PASSWORD=1

のいづれかが必要と書いてあるけど、試した感じでは1.のrootパスワード指定ではWordPressからデータベースにアクセスできなかった。

とりあえず、環境変数で初期設定

MARIADB_RANDOM_ROOT_PASSWORD=1
MARIADB_USER={WordPressで使うユーザ名}
MARIADB_PASSWORD={WordPressで使うユーザのパスワード}
MARIADB_DATABASE={WordPressで使うデータベース名}
TZ=Asia/Tokyo ※日本の場合

コンテナの画面では「変数の追加」ボタンを押すと「一括インポート・・・」の説明が出るので、上の環境変数設定を丸ごとペーストすると楽。

コンテナを作り直す度にデータベースが空になると面倒なので、ボリュームを指定してホストに残るようにする。

ホストパス             コンテナーパス 
{ホスト側のディレクトリィ}  /var/lib/mysql

改めてmariadbコンテナを作る時は初期設定済みなのでボリュームだけ指定すればいい。(ハズ

3.WordPressのコンテナを作る

イメージのとこの【新規イメージのダウンロード】ボタンでイメージをダウンロードしておく。

podのとこの【podでのコンテナーの作成】ボタンで・・・

wordpressもdockerのページを見ると

環境変数がいっぱい必要らしい

WORDPRESS_DB_NAME={WordPressで使うデータベース名}
WORDPRESS_DB_USER={WordPressで使うユーザ名}
WORDPRESS_DB_PASSWORD={WordPressで使うユーザのパスワード}
WORDPRESS_DB_HOST={mariaDBのコンテナ名}

毎回htmlも空になると面倒なので、ボリュームを指定しホストに残す。

ホストパス               コンテナーパス 
{ホスト側のディレクトリィ}  /var/www/html 

改めてwordpressコンテナを作る時は初期設定済みなのでボリュームだけ指定すればいい。(ハズ

注意点としては・・・

/var/www/htmlの下にwp-config.phpが作成されるまで待つこと。

さっさとコンテナを止めたり削除すると作成されないので、環境変数の設定が必要になる。

とりあえず、ここまで無事2個のコンテナが起動できていれば

さーて、ここまでは無事成功したけど・・・

ボリューム指定でホストからwp-config.phpが見れるので再設定できるかな?と思いきや

暗号化されているので再設定するよりコンテナを作り直した方が安心できそう。

ブログの移行をするつもりなら

移行プラグインを使うしかない。

ここまでやってやっと気が付く。

podmanのCLIでpodやコンテナを作って

cockpit-podmanでやることはpodの起動と終了だけにした方が

絶対楽だ(合掌

イメージだけで1Gバイトあるけど

CPUの使用率やメモリ消費量は低いのは

助かる。

ブラウザで記事をちょっと書いた感じでは異様に遅いとかないので、

podmanにブログを移行するのも悪くないかもしれない。



[Almalinux]Cockpit-Podman

コンテナと云えばDockerなんだろうけどRedhatのコマンドから削除され、代わりにPodmanが入ったらしい。

cockpitのアプリケーションの画面にPodmanがあるので【インストール】ボタンを押してみる。

# podman --version
podman version 5.2.2

イメージをダウンロードしてみる。

docker.ioからAlmaLinux9のminimalを選んでダウンロードしてみる

暫くすると

イメージは落とせたらしいので【コンテナーの作成】ボタンを押してコンテナを作る。

で動いてるっぽい。

ここまではいいけど、どう繋げばいいんだろう?

と思ったら「コンソール」タグがあった。

これで何かを付け足せば良いのだろうけど

dnfもtopも何も入ってないのでどうすればいいのかな?

インスト済みのコマンドならホストから実行できる。

# podman exec {コンテナ名} {コマンド} な感じで

# podman exec suspicious_morse ls -l
total 0
dr-xr-xr-x   2 root root   6 Oct  2 21:00 afs
lrwxrwxrwx   1 root root   7 Oct  2 21:00 bin -> usr/bin
drwxr-xr-x   5 root root 360 Mar 26 14:31 dev
drwxr-xr-x   1 root root  18 Mar 26 14:31 etc
drwxr-xr-x   2 root root   6 Oct  2 21:00 home
lrwxrwxrwx   1 root root   7 Oct  2 21:00 lib -> usr/lib
lrwxrwxrwx   1 root root   9 Oct  2 21:00 lib64 -> usr/lib64
drwxr-xr-x   2 root root   6 Oct  2 21:00 media
drwxr-xr-x   2 root root   6 Oct  2 21:00 mnt
drwxr-xr-x   2 root root   6 Oct  2 21:00 opt
dr-xr-xr-x 254 root root   0 Mar 26 14:31 proc
dr-xr-x---   2 root root  91 Mar  7 07:52 root
drwxr-xr-x   1 root root  42 Mar 26 14:31 run
lrwxrwxrwx   1 root root   8 Oct  2 21:00 sbin -> usr/sbin
drwxr-xr-x   2 root root   6 Oct  2 21:00 srv
dr-xr-xr-x  13 root root   0 Mar 26 14:31 sys
drwxrwxrwt   2 root root   6 Oct  2 21:00 tmp
drwxr-xr-x  12 root root 144 Mar  7 07:52 usr
drwxr-xr-x  18 root root 235 Mar  7 07:52 var

できるけどviすら無いから・・・

ただ rpm コマンドは入ってたので・・・

ホストからファイル転送すれば何とかなるかな???????

# podman cp {ホストファイルパス} {コンテナー名} : {コンテナーファイルパス}

外にファイル転送するには

# podman cp {コンテナー名} : {コンテナーファイルパス} {ホストファイルパス}

で使えるらしい。:の有無でホストとコンテナを区別してるっぽいので

# podman cp {コンテナー1} : {コンテナーファイルパス}  {コンテナー2} : {コンテナーファイルパス}

もできそう。

首尾よく何かが出来上がったら、コンテナを停止してイメージを作ればいいのかな。

# podman stop {コンテナー名}  か cockpitのpodmanのコンテナのメニューの【停止】

# podman commit {コンテナー名} {イメージ名} か コンテナのメニューの【コミット】

※「なんたらかんたら」はエラった



[WordPress]画像圧縮してみたが・・・

画像だけで4.1Gバイトもあるので圧縮しようかな?

WordPressのプラグインの圧縮がうまく動かないので

一気にコマンドラインから圧縮

# dnf install pngquant
# find {WordPressインスト先}/wp-content/uploads/20* -name "*.png" -print -exec pngquant --ext .png --force 256 --skip-if-larger {} \;

遅い。

やはりCPU性能でWindowsで圧縮

コピったフォルダで
> for /r . %i in (*.png) do pngquant.exe --ext .png --force 256  --skip-if-larger %i

df -hコマンドで2Gバイト近く減ったので

qemu-img convert -cで圧縮してみるが

さっぱり減らない(謎

# qemu-img info {ブログのqcow2イメージファイル}
・・・
file format: qcow2
virtual size: 50 GiB (53687091200 bytes)
disk size: 12.2 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: AlmaLinux9.qcow2
    protocol type: file
    file length: 12.2 GiB (13084196864 bytes)
    disk size: 12.2 GiB
    Format specific information:
        extent size hint: 1048576

pngquantで画像を圧縮すると

ブログサーバ内ではduコマンドでサイズが減るものの

qcow2イメージファイルで圧縮オプションを指定しているので

kvmがqcow2イメージファイルに書込む際にも圧縮されるけど

一度圧縮したデータを再圧縮しても「あまり圧縮できない」のが普通だから・・・

結局qcow2イメージサイズはほとんど変わらない様だ(終了

ps.2025/3/26

結局、画像を圧縮し、qcow2イメージファイルの圧縮はあまりしない方針にした。

PCで圧縮した画像を転送した時にアップロード先のディレクトリィの所有者が変わってしまい記事に画像を差し込めなくなってた。(汗



[AlmaLinux9]node.jsインスト

# dnf install nodejs

でnodeコマンドは使えるけど、npmが使えないので、こうなった。

# dnf module -y install nodejs:22/common
・・・
===============================================================================================================================================================================================================
 パッケージ                                    アーキテクチャー                    バージョン                                                                     リポジトリー                           サイズ
===============================================================================================================================================================================================================
group/moduleパッケージをインストール:
 nodejs                                        x86_64                              1:22.13.1-1.module_el9.5.0+139+09296491                                        appstream                              1.9 M
 npm                                           x86_64                              1:10.9.2-1.22.13.1.1.module_el9.5.0+139+09296491                               appstream                              2.0 M
依存関係のインストール:
 nodejs-libs                                   x86_64                              1:22.13.1-1.module_el9.5.0+139+09296491                                        appstream                               20 M
弱い依存関係のインストール:
 nodejs-docs                                   noarch                              1:22.13.1-1.module_el9.5.0+139+09296491                                        appstream                              8.6 M
 nodejs-full-i18n                              x86_64                              1:22.13.1-1.module_el9.5.0+139+09296491                                        appstream                              8.6 M
モジュールプロファイルのインストール中:
 nodejs/common                                                                                                                                                                                                
・・・
インストール済み:
  nodejs-1:22.13.1-1.module_el9.5.0+139+09296491.x86_64             nodejs-docs-1:22.13.1-1.module_el9.5.0+139+09296491.noarch         nodejs-full-i18n-1:22.13.1-1.module_el9.5.0+139+09296491.x86_64       
  nodejs-libs-1:22.13.1-1.module_el9.5.0+139+09296491.x86_64        npm-1:10.9.2-1.22.13.1.1.module_el9.5.0+139+09296491.x86_64       
・・・
完了しました!
# node -v
v22.13.1
# npm -v
10.9.2

Expressパッケージで画面を表示したりサービス化するにはpm2パッケージが必須なので入れとく。

# npm install pm2 -g
added 134 packages in 29s

13 packages are looking for funding
  run `npm fund` for details
npm notice
npm notice New major version of npm available! 10.9.2 -> 11.2.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.2.0
npm notice To update run: npm install -g npm@11.2.0
npm notice


[WordPres]IPアドレスアクセス

中にはIPアドレスで探ってくるbotもいるので

IPアドレスでアクセス不可にしてみる。

先のavhost.confに弾く指定を追記

<VirtualHost *:80>
    ServerName any
    <Location />
        Order Deny,Allow
        Deny from all
    </Location>
    ErrorLog logs/ip.addr-error_log
    SetEnvIf Remote_Addr 192.168. no_log
    CustomLog logs/ip.addr-access_log combined env=!no_log
</VirtualHost>

Include avhost/*.conf

これで http://{グローバルIPアドレス}が弾かれる。

調子にのっても<VirtualHost *:443>を追記すると、

なぜか何でも弾かれるので

<VirtualHost {グローバルIPアドレス}>
    ServerName any
    <Location />
        Order Deny,Allow
        Deny from all
    </Location>
    ErrorLog logs/ip.addr-error_log
    # SetEnvIf Remote_Addr 192.168. no_log
    CustomLog logs/ip.addr-access_log combined env=!no_log
</VirtualHost>

に直す。

スマホでドメイン指定OKでIPアドレスでエラるのを確認。

ローカルIPアドレス:443も追加するとLANから見えなくなるからhostsに

{ブログサーバのローカルIPアドレス}   {ブログのドメイン名}

追記してドメイン名でアクセスしても弾かれる謎仕様。

原因がWindowsかApacheかは不明なのでローカルIPアクセス制限は諦めた。



[WordPress]色々ある

ユーザーIDがインターネットで閲覧できるかどうか?

■ ユーザーIDがインターネット上で閲覧可能か確認する方法

/?author=1を試しているbotは多いが

# wget http://{IPアドレス}/?author=1
--2025-03-22 00:47:01--  http://{IPアドレス}/?author=1
{IPアドレス}:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 302 Found
場所: https://ssiscirine.iobb.net [続く]

てな感じで302でトップページにリダイレクトしてたが、特にそんな設定をした覚えはない。

※結果:SiteGuard WP Pluginでユーザ情報を非表示にしてた。

“/?author=数字” のアクセスによるユーザー名の漏えいを防止します。また、REST API によるユーザー名の漏えいを防止するため、REST API を無効化することができます。REST API の無効化によって動作しないプラグインが存在する場合には、除外プラグインのリストにプラグイン名を追加してください。有効になっているプラグインのリストから追加することができます。

なので、REST APIを有効にしないと困るプラグインがありそうだ。

backupPlusも例外に追加

■ 管理画面のアクセス制限が適切か確認する方法

「IDやパスワードを記憶させてない状態のブラウザ」や「シークレットモード」を使用して、管理画面にアクセスする。

普通にログイン画面が開けた。

※結果:apacheのvirsualHostのconfでwp-adminはIPアドレス指定でLAN許可してるからOKだけど

phpMyAdminなどでlogin-failsテーブルを見るといっぱい出るのでPOSTしてくるのかな?

仕方が無いのでログイン画面にBASIC認証を付ける。

試しにwordpressのwp-adminにBASIC認証の.htaccessを入れると・・・

ブログを見る分には支障無いけど、

ログイン画面でCSSが効かなくなり(既に怪しい

ログインを成功すると

内部エラー

になる。

ただの罠でしかないので、apacheのconfファイルに

  <Location "/wp-login.php" >
    AuthType Basic
    AuthName “sample”
    AuthUserFile /{適当なトコ}/.htpasswd
    require valid-user
  </Location>

を追記して一通り(httpdとphp-fpm)再起動。

# htpasswd -c /{適当なトコ}/.htpasswd {アカウント名1}
New password: {パスワード1}
Re-type new password: {パスワード1}
Adding password for user {アカウント名1}
# htpasswd /{適当なトコ}/.htpasswd {アカウント名2}
New password: {パスワード2}
Re-type new password: {パスワード2}
Adding password for user {アカウント名2}
・・・
繰返していくつか作っておく
・・・
支障がありそうなアカウント名の場合は
[1]+  停止                  htpasswd /{適当なトコ}/.htpasswd {htpasswdがアカウント名だと思うモノ}
と出てエラるけど.htpasswdには書かれる

とwp-login.php表示用のBASIC認証アカウントを作る

サイトヘルスの2件のエラー

  • WP-CRONが停止
  • ループバックがタイムアウト

これは、/etc/hostsにブログのドメイン名を追加して

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 ssiscirine.iobb.net

自分に届く様にするとWP-CRONとループバックのエラーが消えた。

単に外面のssiscirine.iobb.netへ送っていたせいでタイムアウトになっていた。

その影響で自分にリクエストを投げていた機能がとても遅かったが素早くなった。(よかったよかった

サイトヘルスの警告

〇停止中のテーマを削除

これは無視

〇予約したイベントの実行に失敗した

要調査

〇1つ以上の推奨モジュールがありません

オプションのモジュール imagick がインストールされていないか、無効化されています。

php.iniに追記

extension = imagick.so

しかし、/etc/php.dにそれらしきsoファイルは無いのでインスト

参照URL:Almalinux 9 で ImageMagickをインストールする

# dnf --enablerepo=epel install ImageMagick-perl        # 177 packages
# dnf --enablerepo=epel install ImageMagick             #   1 packages
# dnf --enablerepo=epel install ImageMagick-devel       #   5 packages
# dnf -y install php-devel                              #  38 packages
# pecl install imagick
・・・
(とても長いので中略)
・・・
Build process completed successfully
Installing '/usr/lib64/php/modules/imagick.so'
Installing '/usr/include/php/ext/imagick/php_imagick_shared.h'
install ok: channel://pecl.php.net/imagick-3.7.0
configuration option "php_ini" is not set to php.ini location
You should add "extension=imagick.so" to php.ini
# find / -name imagick.so -print
/usr/lib64/php/modules/imagick.so
# systemctl restart httpd
# systemctl restart php-fpm

imagick.soだけで183パケもインストされるのは気味が悪い。

libraw_r.so.23()(64bit)が無くてインストする場合もあるらしいけど今回は無事成功。

推奨モジュール云々の警告は消えた。

それにしてもimagick.soを使っていそうなのは画像のリサイズくらいだろうか?

インストしなくてもリサイズできてる気がするが・・・(謎

〇永続性オブジェクトキャッシュを使用してください

高価な環境らしいので無視

〇ページキャッシュが検出できませんでしたが、サーバーのレスポンスは良好です

ページキャッシュプラグインを入れても変わらないので無視

ps.2025/03/22

あいかわらずxmprpc.phpでログインアタックしてくるので

  <Location "/xmlrpc.php" >
    AuthType Basic
    AuthName “sample”
    AuthUserFile /{適当なトコ}/.htpasswd
    require valid-user
  </Location>

xmprpc.phpをブラウザで表示する

XML-RPC サーバーは POST リクエストのみを受け入れます。

と表示する。

JavaScriptで適当にPOSTしてみると

<methodResponse>
	<fault>
		<value>
			<struct>
				<member>
				<name>faultCode</name>
				<value>
					<int>-32700</int>
				</value>
				</member>
				<member>
				<name>faultString</name>
				<value>
					<string>parse error. not well formed</string>
				</value>
				</member>
			</struct>
		</value>
	</fault>
</methodResponse>

とエラるし Site Guardのログイン履歴にすら載らなかった。



[AlmaLinux]mariaDBが動かない

再起動したら・・・

巷では放置サイトでよく見かける

WordPressのDB接続エラーの画面

journalctl -xeu mariadb.serviceで状況を見ると

最初は

No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically.

と出ていたのでロック状態かなと思って削除してみるも動かない

Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
If this is not the case, make sure the /var/lib/mysql is empty before running mariadb-prepare-db-dir.

状況が良く解らないから初期化してね?(怖いよ

ということでログ(/var/log/mariadb/mariadb.log)を見る

[ERROR] InnoDB: Cannot replay rename of tablespace 1122 from './{DB名}/#sql-alter-317-ec.ibd' to './{DB名}/wp_wpo_404_detector.ibd' because the target file exists
[ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption

というので、wp_wpo_404_detector.ibdを消したら、起動できた。

中身は空っぽだからいいか




top