2025-08-04

CentOSの後継についてのチラ裏的日記

裏取りもなにもしていないただの雑感、読む必要はないです

今日、オープンソースカンファレンス京都で AlmaLinux のセミナーを聞いてきた。

CentOS が Red Hat に買収？(なんかボードメンバーがどんどんRedHatの人に入れ替わって、最終的に乗っ取られたという雰囲気ことを話してられた気がするので、どういう経緯でCentOSがRedHatの影響下に取り込まれて、ああいう結末になったのか、の経緯ちゃんっと調べてなかったので知りたい）されて結局 RHEL の互換として使えなくなって、次はどうするかということになったあと、RockyLinux と AlmaLinux が出てきて、じゃあどちらを採用するかという問題があったときに、自分はその時の会社で重要なアプリが RockyLinux での動作保証をしたということと、RockyLinux が RHEL とソースからのリビルドでバグレベルの互換を持っているということで、RockyLinux の方を使おうかと決めた経緯があった。

その後転職して今の会社でも CentOS の後継には Rocky の方を使用している。こっちはなんで Rocky を選択したのかは来ていないのでまた確認しないとなーとは思ってる。

あと Rocky はどこだったかの企業が方針を決めていて、Alma はコミュニティベースというところでサポートに対する不安があったというのもあるか。

ところが今日 AlmaLinux の話を聞いたところでは、RedHat は RHEL のリポジトリからソースを持ってきてリビルドするのはやめてほしいと思っていて、RedHatのサブスクリプション契約？でもそういうことは禁止している、でも Rocky はどっかからソースコードを持ってきているという話があるらしい。　そういえばちょっと前に、そういうライセンス違反的なことをしているのではないかと疑われたが、Rocky 側はそういうことはしていないと反論してたってのがあった。

Almaの方はそういうことをせずにABI互換ということで、(RHELと厳密な互換は落ちるのかな？そもそもABI互換がなんなのかわからん)RHELの蒸留開発リポジトリにあたる Fedra や CentOS Stream からソースをもってきて作っているのでライセンス違反的な要素はないということだった。

いまのところ RockyLinux は企業が管理していて、RHELとバイナリレベル互換があるということなので、エンプラ的には安定してそうだけど、今後RedHatともめたり、また買収とかいうはなしになると継続性にちょっと疑問があるのかなぁという印象を持つようになってしまった。

Almaの方はコミュニティベースでボードメンバーが投票で選ばれて運営してて、公開されているソースからRHELのABI互換を目指しているということで、継続性はありそうな気がする。

そもそもRHELとの厳密な互換性が問題になるならRHEL使っとけばいいだけではあるわな

今まではRockyの方を使ってきたけど、Almaに徐々に乗り換えるべきかなーという気がしてきている。

今日説明されていた人は Rocky に対する言及が慎重だったので、その人にどっちがいいってのは聞きにくかったというのもあるし、一方的に AlmaLinux の意見を聞いたので、どっかで RockyLinux の人のセミナーも聞いてみたいとは思う。

2025-08-04

OpenSSLで独自CAを作成してApacheにクライアント証明書認証を設定する方法（Amazon Linux 2023対応）

ChatGPTに聞きながら設定したので、自分のメモとして整理して残す

目的

OpenSSLで独自認証局（CA）を作成
クライアント証明書を発行
Apacheにクライアント証明書によるアクセス制限を設定

🛠 1. CA（認証局）の構築

CAディレクトリ構成の準備

mkdir -p ~/myCA/{certs,crl,newcerts,private}
chmod 700 ~/myCA/private
touch ~/myCA/index.txt
echo 1000 > ~/myCA/serial

openssl.cnf の準備

cp /etc/pki/tls/openssl.cnf ~/myCA/openssl.cnf

必要に応じて dir = /home/ユーザー名/myCA や [ usr_cert ] セクションなどを編集してください。

主には dir、certificate、private_key、certs の項目をこの後設定していくファイル名に変更しておく

dir           = /home/user/myCA
certificate   = $dir/certs/ca.cert.pem
private_key   = $dir/private/ca.key.pem
certs         = $dir/certs/ca.cert.pem

CAの秘密鍵を作成

openssl genpkey -algorithm RSA -out ~/myCA/private/ca.key.pem \
    -aes256 -pkeyopt rsa_keygen_bits:4096
chmod 400 ~/myCA/private/ca.key.pem

CAの自己署名証明書を発行

openssl req -config ~/myCA/openssl.cnf \
    -key ~/myCA/private/ca.key.pem \
    -new -x509 -days 3650 -sha256 -extensions v3_ca \
    -out ~/myCA/certs/ca.cert.pem
chmod 444 ~/myCA/certs/ca.cert.pem

クライアント証明書の作成

秘密鍵とCSRの作成

openssl genpkey -algorithm RSA -out client.key.pem -pkeyopt rsa_keygen_bits:2048
openssl req -new -key client.key.pem -out client.csr.pem

CAで署名して証明書発行

openssl ca -config ~/myCA/openssl.cnf \
    -extensions usr_cert \
    -days 365 \
    -notext \
    -md sha256 \
    -in client.csr.pem \
    -out client.cert.pem

クライアント配布用 .p12 ファイル作成

openssl pkcs12 -export \
    -inkey client.key.pem \
    -in client.cert.pem \
    -certfile ~/myCA/certs/ca.cert.pem \
    -out client.p12

※作成時にパスワード入力が求められます。

Apacheへの設定

Apache SSL設定ファイルの編集（例：/etc/httpd/conf.d/ssl.conf）

SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key

SSLCACertificateFile /home/user/myCA/certs/ca.cert.pem
SSLVerifyClient require
SSLVerifyDepth 1

Apacheの再起動

sudo systemctl restart httpd

クライアント証明書でのアクセス確認

client.p12 をクライアント端末に配布、

Windows/macOS/ブラウザにインポート

サーバへアクセス → 証明書選択を求められる

補足：特定のパスだけ制限する場合

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile ...
    SSLCertificateKeyFile ...
    SSLCACertificateFile ...

    <Location "/secure/">
        SSLVerifyClient require
        SSLVerifyDepth 1
    </Location>
</VirtualHost>

2025-07-27

# AWS の EBS をオンラインで追加する

EC2 で容量が不足してきたときには、EBS を拡張してお手軽に容量を追加することができる。

容量の追加は簡単だが、減らす機能はない。どうしても減らしたければ別の EBS を作成してそこにコピーしていくことになります。

容量を追加することに比べると減らすほうは面倒くさすぎるので、EBS は小さ目に作って、必要に応じて追加するほうが楽。

EBS の容量追加

lsblk df -h コマンドで容量を確認しておきます。

ec2-user@ip-10-0-1-223 ~]$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0   8G  0 disk
tqnvme0n1p1   259:1    0   8G  0 part /
tqnvme0n1p127 259:2    0   1M  0 part
mqnvme0n1p128 259:3    0  10M  0 part /boot/efi
[ec2-user@ip-10-0-1-223 ~]$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             453M     0  453M   0% /dev/shm
tmpfs             181M  424K  181M   1% /run
/dev/nvme0n1p1    8.0G  1.5G  6.5G  19% /
tmpfs             453M     0  453M   0% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              91M     0   91M   0% /run/user/1000```

追加作業だけならまず問題はないですが、スナップショットはとっておきましょう。

スナップショットを取ったら EC2 の Elastic Block Store > ボリュームで拡張したいボリュームを選択して、右にある[変更]をクリック

[ボリュームの変更]画面になるので、ボリュームのサイズを増やして、[変更]をクリック

確認画面が出るので、そのまま[変更]をクリック

追加する容量によっては時間がかかる場合もありますが、AWS内の修正が終われば追加された容量が表示されます。

インスタンスにログインをして容量を確認します

[ec2-user@ip-10-0-1-223 ~]$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0  16G  0 disk
tqnvme0n1p1   259:1    0   8G  0 part /
tqnvme0n1p127 259:2    0   1M  0 part
mqnvme0n1p128 259:3    0  10M  0 part /boot/efi

16G に増えています。

パーティション領域は増えていないので、growpart コマンドで tqnvme0n1p1 のパーティション領域を増やします。

ec2-user@ip-10-0-1-223 ~]$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0  16G  0 disk
tqnvme0n1p1   259:1    0   8G  0 part /
tqnvme0n1p127 259:2    0   1M  0 part
mqnvme0n1p128 259:3    0  10M  0 part /boot/efi
[ec2-user@ip-10-0-1-223 ~]$ sudo growpart /dev/nvme0n1 1
CHANGED: partition=1 start=24576 old: size=16752607 end=16777183 new: size=33529823 end=33554399
[ec2-user@ip-10-0-1-223 ~]$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0  16G  0 disk
tqnvme0n1p1   259:1    0  16G  0 part /
tqnvme0n1p127 259:2    0   1M  0 part
mqnvme0n1p128 259:3    0  10M  0 part /boot/efi

growpart コマンドでパーティション領域は増えるが、ファイルシステムは増えないので、ext4 の場合は resize2fs、xfs の場合は xfs_growfs でファイルシステムを拡張します。

[ec2-user@ip-10-0-1-223 ~]$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             453M     0  453M   0% /dev/shm
tmpfs             181M  432K  181M   1% /run
/dev/nvme0n1p1    8.0G  1.5G  6.5G  19% /
tmpfs             453M     0  453M   0% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              91M     0   91M   0% /run/user/1000
[ec2-user@ip-10-0-1-223 ~]$ sudo xfs_growfs /
meta-data=/dev/nvme0n1p1         isize=512    agcount=2, agsize=1047040 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1
data     =                       bsize=4096   blocks=2094075, imaxpct=25
         =                       sunit=128    swidth=128 blks
naming   =version 2              bsize=16384  ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=4096  sunit=4 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2094075 to 4191227
[ec2-user@ip-10-0-1-223 ~]$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             453M     0  453M   0% /dev/shm
tmpfs             181M  432K  181M   1% /run
/dev/nvme0n1p1     16G  1.6G   15G  10% /
tmpfs             453M     0  453M   0% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              91M     0   91M   0% /run/user/1000

無事容量が増えました。

2025-05-24

git で日本語ファイル名を使

git で日本語ファイル名を使う

git で日本語ファイル名を使うのは邪道なので不許可。以上！

と思うのだけど、使いたいので使う方法をいろいろ調査、というかいつも忘れるのでまとめる

日本語ファイル名化け

git で日本語ファイル名を使用していると git status などを行ったとき文字化けする。

Windows は、ファイルシステム上のファイル名を UTF-16 で扱っているが、git はもともと Linux 文化のツールで、内部的にファイル名を UTF-8 で処理している。

なので、Windows 上で Git を動かすとき、Git はファイル名を UTF-8 として認識しようとするが、 PowerShell や CMD の文字コードが UTF-8 でないため出力結果がコンソールで文字化けする。

解決方法としては Git 出力のマルチバイト文字をエスケープしないで、そのまま表示するのが手っ取り早い

git config --global core.quotepath false

この状態で commit して push すれば github 上でもちゃんと日本語として表示される。

git config --global はそのマシンのそのユーザ弐のみ影響するので、ほかの環境ではまた同じことをする必要がある。

2025-05-18

Apacheで `/tmp` に書き込めない原因と対処方法（PrivateTmp）

◆ 現象

Apache（httpd）上の php から /tmp にファイルを書き込もうとした際に、ファイルが作成されなくて半日なやんだ。　結果としては systemd で PrivateTmp が有効になっていたのが原因だった。

◆ 主な原因：systemd の `PrivateTmp` 機能

Apache の systemd サービスファイルで PrivateTmp=true が設定されている場合、Apache は他のプロセスとは隔離された独自の /tmp 領域（例：
/tmp/systemd-private-xxxx-httpd.service-XXXX/tmp）を使う。

そのため、/tmp に書いているつもりでも、実際には他プロセスから見えない場所に書き込まれている。

◆ PrivateTmp の確認方法

以下のコマンドで Apache の systemd 設定を確認する：

systemctl cat httpd.service

出力内に以下のような行があれば PrivateTmp が有効：

[Service]
PrivateTmp=true

◆ 対処方法：`PrivateTmp=false` に変更して無効化する

1. 設定用ディレクトリを作成

mkdir -p /etc/systemd/system/httpd.service.d

2. 設定ファイルを作成

vi /etc/systemd/system/httpd.service.d/override.conf

ファイル内容：

[Service]
PrivateTmp=false

3. 設定の再読み込みと Apache 再起動

systemctl daemon-reexec
systemctl daemon-reload
systemctl restart httpd

◆ 注意点

PrivateTmp=false にすると、Apache からシステム共通の /tmp が見えるようになるが、セキュリティ上のリスクが高まる可能性がある。

自分の場合は、php から 'form method="post" enctype="multipart/form-data">' でファイルをアップしたくて、その場合 /tmp へ書き込むのでどうしても /tmp に書き込みができるようにしなければならないという都合を優先した。

◆ 追記

この問題、PrivateTmp の設定を変更するより、php の ini_set 使って、設定変更する方が素直だった。

// 一時ディレクトリとアップロード先のディレクトリ
$tmpDir = '/var/www/html/tmp';

// 一時ディレクトリがなければ作成
if (!is_dir($tmpDir)) {
    if (!mkdir($tmpDir, 0700, true)) {
        die("一時ディレクトリの作成に失敗しました: $tmpDir");
    }
}

// PHPに一時ディレクトリを設定
ini_set('upload_tmp_dir', $tmpDir);

2024-07-29

Markdown でマニュアルの作成

Markdown 楽だよねってことで、Markdown で業務マニュアル作成することにしたので、その手順のまとめ

VSCode の Markdown 用の拡張をいくつかインストールしておく

Markdown All in One、目次の作成と章番号の追加など
Markdown Preview Enhanced、Markdown のプレビュー
Markdownlint、書式の確認
Markdown PDF、PDFへの出力

1. マニュアルの記述

Markdownを使ってマニュアルを作成していく。

mdファイルの上で右クリックして、「Markdown Preview Enhanced Open Preview to the Side」でプレビュー画面が右ペインに表示される。

mdファイルを編集すれば自動的に更新されていくのでWYSIWYGで編集できる。

# を使って章番号を設定しておくと VSCode の左にあるアウトラインから章に移動することができる。便利

編集内容に問題があれば Markdownlint が下線で警告してくれるので、クリックすると修正内容を提案してくれる。

画像などは必要なところに直接コピペすると、![alt text](image-1.png) という感じで貼り付けてくれる。

便利だけど理想的には images ディレクトリを作成しておき、そこに保存をして、 ![画像名](画像ファイルへの相対パス) な感じで修正したほうがいいかもしれない。

2. 章番号と目次の作成

VSCode のコマンドパレットを開いて(Windows:Ctrl+Shift+p、Mac:Shift+Command+p) Markdown All In One のコマンドで章番号、目次の作成できる。

章番号の追加、更新は Markdown All in One: Add/Update section numbers

章番号、目次に含めたくない場合は  を見出し行の前にいれておく。

見出しを追加更新した場合には再度Add/Update section numbersを実行して章番号を更新する。

目次は Markdown All in One: Create Table of Contents で目次を作成してくれる。

作成した目次はリンクになっているのでそこから対象へ移動することができる。

3. PDF化

作成したマニュアルをPDF化したい場合には、mdファイルを右クリックして「Markdown PDF: export (PDF)」でPDFファイルにすることができる。

4. 余談

もともとは Word で作成するつもりだったのだが、ざっくり見出しを作った時点で7章、100項目以上になりそうで、サブ文章に分けることとか、アウトラインで編集するなど考えたのだが差分も取りにくいし画像のいちとかレイアウトを考えるのも大変ということで Markdown で書くことにした。

Wordのアウトラインモードで画像や表の扱いがらくになるとか、履歴差分がわかりやすくなる方法などがあればもうちょっとWordも検討対象になったのだが。

2024-07-25

GitHub Webhooks をつかて push したらデプロイ

以前の記事でgit の hooks を使って push したらWebサーバにデプロイする環境を構築してみたがやっぱり push 先が2つになるのはめんどくさいので GitHub に push したらWebサーバにもデプロイされるようにしたい。

リポジトリはプライベート
Webhook でデプロイ先のURLへアクセス
URLにアクセスされたら、git pull を実行

という単純なものにするのでセキュリティなどは考慮しない。

ただこの場合 apache の権限で git pull されることになるので、Webページのファイル、ディレクトリ権限が apache で読み書きできるものになる。

apache へ ssh キーの設定

/etc/passwd ファイルを確認して apache のホームディレクトリを探し、そこに .ssh ディレクトリを作成して、鍵ファイルを作成する。

# cat /etc/passwd | grep apache
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
# cd /usr/share/httpd/
# mkdir .ssh
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /usr/share/httpd/.ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /usr/share/httpd/.ssh/id_rsa.
Your public key has been saved in /usr/share/httpd/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:wa8n56*************************lC3oon9kGD8 root@example.com
The key's randomart image is:
+---[RSA 3072]----+
|        .+o      |
|       . .o      |
|   . . .o+.o     |
|. . * . *o+.     |
|.= = = =Soo      |
|o = B E .. .     |
| . * B oo + o    |
|  o   .  * +..   |
|   ...    +o.    |
+----[SHA256]-----+
# chown -R apache:apache /usr/share/httpd/.ssh
# chmod -R 700 /usr/share/httpd/.ssh
# cat /usr/share/httpd/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAA(略)GWVQM9fcb0VXJhTM= root@example.com
#

鍵ファイルを作成したら公開鍵をコピーして、GitHub のアカウントから「Settings」を開き、「SSH and GPG keys」の「SSH Keys」の「New SSH Key」ボタンを押す。

SSH Keyの登録画面になるので、「Title」に識別しやすい名前をつけて、先ほど作成した id_rsa.pub の中身を「Key」貼り付けて、「Add SSH Key」をクリックする。

これでこの現在のアカウントに新しい SSH Key が登録される。

更新用URLの作成

ごく簡単なphpスクリプトで更新用のphpファイルを作成する。

アクセスされても更新されるだけのURL

<?php
system('cd /path/to/web_directory');
system('git pull origin master');

作成した php ファイルの URL にアクセスして、「Already up to date.」とかのメッセージが表示されていることを確認する。

Webhooks の設定

GitHub の資料がわかりやすい。

Webhooks を設定したいリポジトリを開いて、リポジトリの「Settigs」を開き、「Webhooks」を開く。

「Add Webhook」ボタンをクリックして、「Payload URL」に先ほど作成した更新用のURLを貼り付ける。

特にデータのやり取りなどがあるわけでもないのでその他の場所はそのままにして「Add webhook」で作成する。

確認

以上でできたはずなので動作確認。

webhook を設定する前に更新用URLを開いてページが更新されることを確認しておけば確実。

あとは GitHub に push すれば自動的に更新される。

目的