タイトルリスト
MBRパーティションとGPTパーティションの混在でgmirrorを作る→その後両方ともGPTパーティションに変更(2019/10/09 08:00:17)
MBRパーティションの内容をGPTパーティションにdump/restoreを使わずにコピーする(2019/10/09 07:09:41)
GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)(2019/10/09 08:07:20)
gmirrorのディスクサイズを広げてみる(MBR)(2019/10/06 05:03:58)
[修正版] ディスクスペースを拡張してみる＠物理ディスク(2019/10/06 04:34:55)
gmirrorの使い方(2019/10/09 00:56:23)
gmirroで組んでいたRAIDがクラッシュ(2019/10/05 20:56:02)
ディスクスペースを拡張してみる＠VMware(2018/10/01 00:27:44)
Let's Encryptの証明書をapache 2.2にインストールするときのはまりどころ(2018/09/24 02:23:40)
certbot-autoの--pre-hookと--deploy-hookと--post-hook(2018/09/22 04:00:20)
Let's Encryptでワイルドカード証明書を発行する その2(2018/09/21 19:05:22)
MewとTLS(STARTTLS)とSSL(SMTP over SSL)と(2018/09/20 01:37:13)
MewでSSL over POP3/SMTPが使えなくなった(2018/09/20 01:47:35)
Let's Encryptでワイルドカード証明書を発行する(2018/09/18 13:37:20)
台風21号とサーバーメンテナンス(2018/09/06 10:02:21)
MBRパーティションの内容をGPTパーティションにdump/restoreを使わずにコピーする(2019/10/09 07:09:41)
GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)(2019/10/09 08:07:20)
gmirrorのディスクサイズを広げてみる(MBR)(2019/10/06 05:03:58)
[修正版] ディスクスペースを拡張してみる＠物理ディスク(2019/10/06 04:34:55)
gmirrorの使い方(2019/10/09 00:56:23)
gmirroで組んでいたRAIDがクラッシュ(2019/10/05 20:56:02)
ディスクスペースを拡張してみる＠VMware(2018/10/01 00:27:44)
Let's Encryptの証明書をapache 2.2にインストールするときのはまりどころ(2018/09/24 02:23:40)
certbot-autoの--pre-hookと--deploy-hookと--post-hook(2018/09/22 04:00:20)
Let's Encryptでワイルドカード証明書を発行する その2(2018/09/21 19:05:22)
MewとTLS(STARTTLS)とSSL(SMTP over SSL)と(2018/09/20 01:37:13)
MewでSSL over POP3/SMTPが使えなくなった(2018/09/20 01:47:35)
Let's Encryptでワイルドカード証明書を発行する(2018/09/18 13:37:20)
台風21号とサーバーメンテナンス(2018/09/06 10:02:21)
2019/10/09
MBRパーティションとGPTパーティションの混在でgmirrorを作る→その後両方ともGPTパーティションに変更
説明の想定としては、
gmirror は MBR パーティションと GPT パーティションの混在も可能のようだが、両方ともパーティション単位で指定すること。
MBR パーティションをドライブ全体で指定してしまうと、ミラーされる側 (GPT パーティション：ここでは ada3p1) が ada3p1s1d なんて超へんてこなデバイス名になってしまう。(笑)
作業的には前途の通り。
→ GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)
> MBR パーティションをドライブ全体で指定してしまうと、ミラーされる側 (GPT パーティション：ここでは ada3p1) が ada3p1s1d なんて超へんてこなデバイス名になってしまう。(笑)
だが、やってみるとこんなことになる。
現在 2TB 未満のディスクを使って gmirror を構築しているが、ディスク障害によるディスク交換で将来的に 2TB を超える HDD にアップグレードを考えているため、ミラーの方肺を 2TB 以上の HDD に置き換え、その後両方とも 2TB を超える HDD に揃える。といった状況の下で説明とする。
gmirror は MBR パーティションと GPT パーティションの混在も可能のようだが、両方ともパーティション単位で指定すること。
MBR パーティションをドライブ全体で指定してしまうと、ミラーされる側 (GPT パーティション：ここでは ada3p1) が ada3p1s1d なんて超へんてこなデバイス名になってしまう。(笑)
% gpart show ada2 ada2s1 ada3
=> 63 10485697 ada2 MBR (5.0G)
63 10485657 1 freebsd [active] (5.0G)
10485720 40 - free - (20K)
=> 0 10485657 ada2s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 4 freebsd-ufs (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% gpart show -lp ada2 ada2s1 ada3
=> 63 10485697 ada2 MBR (5.0G)
63 10485657 ada2s1 (null) [active] (5.0G)
10485720 40 - free - (20K)
=> 0 10485657 ada2s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 ada2s1d (null) (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 ada3p1 (null) (8.0G)
% sudo gmirror label -v mirror0 ada2s1d
Metadata value stored on ada2s1d.
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2s1d (ACTIVE)
% gmirror insert -v mirror0 ada3p1
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2s1d (ACTIVE)
ada3p1 (ACTIVE)
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 3646045765
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368647680 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada2s1d
Mediasize: 5368648192 (5.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 40448
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 2017605693
2. Name: ada3p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 3326642448
% sudo mount /dev/mirror/mirror0 /mnt
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/mirror/mirror0 5061568 28072 4628572 1% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 07:40 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 07:40 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 07:40 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 07:40 mikofuku_dd-dy_manual.pdf*
% sudo umount /mnt
更にこの後に MBR パーティションを持った小さなドライブから GPT パーティションを持った大きなドライブに入れ替える場合は、MBR の小さなドライブを remove してから GPT の大きなドライブを insert して growfs で広げる。作業的には前途の通り。
→ GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)
> MBR パーティションをドライブ全体で指定してしまうと、ミラーされる側 (GPT パーティション：ここでは ada3p1) が ada3p1s1d なんて超へんてこなデバイス名になってしまう。(笑)
だが、やってみるとこんなことになる。
% sudo gmirror label -v mirror0 ada2
Metadata value stored on ada2. Done. % gmirror status Name Status Components mirror/mirror0 COMPLETE ada2 (ACTIVE) % gmirror insert -v mirror0 ada3p1 Done. % gmirror status Name Status Components mirror/mirror0 COMPLETE ada2 (ACTIVE) ada3p1 (ACTIVE) % gmirror list mirror0 Geom name: mirror0 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 1111266501 Type: AUTOMATIC Providers: 1. Name: mirror/mirror0 Mediasize: 5368708608 (5.0G) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: ada2 Mediasize: 5368709120 (5.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3283235968 2. Name: ada3p1 Mediasize: 8589893632 (8.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 2283151022 % gmirror destroy mirror0 % % ll /dev/ada3* crw-r----- 1 root operator - 0x60 10月 9 06:16 /dev/ada3 crw-r----- 1 root operator - 0x67 10月 9 06:38 /dev/ada3p1 crw-r----- 1 root operator - 0x76 10月 9 07:43 /dev/ada3p1s1 crw-r----- 1 root operator - 0x88 10月 9 07:43 /dev/ada3p1s1d
% gpart destroy -F ada3 ada3 destroyed % ll /dev/ada3* crw-r----- 1 root operator - 0x60 10月 9 06:16 /dev/ada3
- NO COMMENT -
TrackBack URL:[編]
MBRパーティションの内容をGPTパーティションにdump/restoreを使わずにコピーする
MBR パーティションから GPT パーティションに dump | restore を使わずにコピーする方法。
どちらもパーティション単位で dd if of すれば良い。
パーティション情報的には大きくなってるので growfs だけで事足りる
どちらもパーティション単位で dd if of すれば良い。
% gpart show ada2 ada2s1 ada3
=> 63 10485697 ada2 MBR (5.0G)
63 10485657 1 freebsd [active] (5.0G)
10485720 40 - free - (20K)
=> 0 10485657 ada2s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 4 freebsd-ufs (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% gpart show -lp ada2 ada2s1 ada3
=> 63 10485697 ada2 MBR (5.0G)
63 10485657 ada2s1 (null) [active] (5.0G)
10485720 40 - free - (20K)
=> 0 10485657 ada2s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 ada2s1d (null) (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 ada3p1 (null) (8.0G)
% sudo mount -v /dev/ada2s1d /mnt
/dev/ada2s1d on /mnt (ufs, local, writes: sync 2 async 0, reads: sync 3 async 0, fsid a1f99c5d0a3d3046)
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada2s1d 5061568 28072 4628572 1% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 06:04 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 06:03 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 06:04 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 06:04 mikofuku_dd-dy_manual.pdf*
% sudo umount -v /mnt
/dev/ada2s1d: unmount from /mnt
% sudo dd if=/dev/ada2s1d of=/dev/ada3p1 bs=2M
2559+1 records in
2559+1 records out
5368648192 bytes transferred in 2.444914 secs (2195842973 bytes/sec)
% gpart show ada2 ada2s1 ada3
=> 63 10485697 ada2 MBR (5.0G)
63 10485657 1 freebsd [active] (5.0G)
10485720 40 - free - (20K)
=> 0 10485657 ada2s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 4 freebsd-ufs (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% sudo mount -v /dev/ada3p1 /mnt
/dev/ada3p1 on /mnt (ufs, local, writes: sync 2 async 0, reads: sync 3 async 0, fsid a1f99c5d0a3d3046)
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada3p1 5061568 28072 4628572 1% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 06:04 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 06:03 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 06:04 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 06:04 mikofuku_dd-dy_manual.pdf*
% sudo umount -v /mnt
/dev/ada3p1: unmount from /mnt
5GB の MBR パーティションを 8GB の GPT パーティションにコピーしたら 5GB になっちゃったので広げましょう。パーティション情報的には大きくなってるので growfs だけで事足りる
% gpart show ada3
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% sudo growfs -N /dev/ada3p1
super-block backups (for fsck_ffs -b #) at:
11542656, 12825152, 14107648, 15390144, 16672640
% sudo growfs /dev/ada3p1
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ada3p1 from 5.0GB to 8.0GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
11542656, 12825152, 14107648, 15390144, 16672640
% sudo mount -v /dev/ada3p1 /mnt
/dev/ada3p1 on /mnt (ufs, local, writes: sync 2 async 0, reads: sync 3 async 0, fsid a1f99c5d0a3d3046)
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada3p1 8106676 28072 7430072 0% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 06:04 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 06:03 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 06:04 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 06:04 mikofuku_dd-dy_manual.pdf*
% sudo umount -v /mnt
/dev/ada3p1: unmount from /mnt
- NO COMMENT -
TrackBack URL:[編]
GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)
詳細な説明は端折っているので、おおまかな流れは MBR のそれを参照してください。
→gmirrorのディスクサイズを広げてみる(MBR)
GPT パーティションを gmirror で使用する場合は MBR の時のようにディスク全体を指定することが出来ません。
つまり、パーティショニングスキームが GPT の場合は MBR と違い、GPT パーティション単位でミラー設定を行わなければならない。
でもなんで MBR じゃなくて GPT かって？
MBR は 2TB までのディスクしか扱えないので、それ以上を扱いたいなら GPT しかないのです…。
MBR パーティションの時は RAID-1 パーティション (ここでは mirror0) に対して gpart resize を使用したが、GPT パーティションの場合はそれが不要になっているので gmirror resize するだけでパーティションサイズを大きく出来る。
ここからはダメな例とか詳細な説明とか。
↓ダメな例
FreeBSD Handbook
18. GEOM: Modular Disk Transformation Framework
18.3. RAID1 - Mirroring
18.3.1. Metadata Issues
ここで注意する点は「両方同じパーティションテーブルを持ったパーティションが必要」ということだが、ぶっちゃけ後から追加するディスクが大きければ必ずしも同じパーティションテーブルでなくても良い。
仮にパーティションサイズが元居たパーティションサイズよりも小さい場合はこうなります。
gpart destroy で Device busy と怒られたら -F で強制的にデストローイ！！！
→gmirrorのディスクサイズを広げてみる(MBR)
GPT パーティションを gmirror で使用する場合は MBR の時のようにディスク全体を指定することが出来ません。
つまり、パーティショニングスキームが GPT の場合は MBR と違い、GPT パーティション単位でミラー設定を行わなければならない。
でもなんで MBR じゃなくて GPT かって？
MBR は 2TB までのディスクしか扱えないので、それ以上を扱いたいなら GPT しかないのです…。
% gpart show -lp ada2 ada3
=> 40 10485680 ada2 GPT (5.0G)
40 10485680 ada2p1 (null) (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 ada3p1 (null) (8.0G)
% sudo gmirror label -v mirror0 ada2p1
Metadata value stored on ada2p1.
Done.
% gmirror insert -v mirror0 ada3p1
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2p1 (ACTIVE)
ada3p1 (ACTIVE)
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 315191848
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368667648 (5.0G) ←★小さい方に合わせられる
Sectorsize: 512
Mode: r1w1e1
Consumers:
1. Name: ada2p1
Mediasize: 5368668160 (5.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 2366964925
2. Name: ada3p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 1280267142
% sudo mount /dev/mirror/mirror0 /mnt
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/mirror/mirror0 5061588 28072 4628592 1% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 04:32 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 04:31 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 04:32 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 04:32 mikofuku_dd-dy_manual.pdf*
今度は小さいドライブ (ada2) を外して大きなドライブ (ada4) に交換する。MBR パーティションの時は RAID-1 パーティション (ここでは mirror0) に対して gpart resize を使用したが、GPT パーティションの場合はそれが不要になっているので gmirror resize するだけでパーティションサイズを大きく出来る。
% gmirror remove -v mirror0 ada2p1
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada3p1 (ACTIVE)
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 1
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 1795428709
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368667648 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada3p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 1783526678
% gpart show ada4
=> 40 16777136 ada4 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% gpart show -lp ada4
=> 40 16777136 ada4 GPT (8.0G)
40 16777136 ada4p1 (null) (8.0G)
% gmirror insert -v mirror0 ada4p1
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada3p1 (ACTIVE)
ada4p1 (ACTIVE)
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 1795428709
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368667648 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada3p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 1783526678
2. Name: ada4p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 2699217139
% sudo mount /dev/mirror/mirror0 /mnt
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/mirror/mirror0 5061588 28072 4628592 1% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 06:39 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 06:39 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 06:39 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 06:39 mikofuku_dd-dy_manual.pdf*
% sudo umount /mnt
% gmirror resize mirror0
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 1795428709
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 8589893120 (8.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada3p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 1783526678
2. Name: ada4p1
Mediasize: 8589893632 (8.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 20480
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 2699217139
% growfs -N /dev/mirror/mirror0
super-block backups (for fsck_ffs -b #) at:
11542656, 12825152, 14107648, 15390144, 16672640
% sudo growfs /dev/mirror/mirror0
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/mirror/mirror0 from 5.0GB to 8.0GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
11542656, 12825152, 14107648, 15390144, 16672640
% sudo mount /dev/mirror/mirror0 /mnt
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/mirror/mirror0 8106672 28072 7430068 0% /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 06:39 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 06:39 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 06:39 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 06:39 mikofuku_dd-dy_manual.pdf*
増えました。:)ここからはダメな例とか詳細な説明とか。
↓ダメな例
% gpart show -lp ada2 ada3
=> 40 10485680 ada2 GPT (5.0G)
40 10485680 ada2p1 (null) (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 10485680 ada3p1 (null) (5.0G)
10485720 6291456 - free - (3.0G)
% sudo mount /dev/ada2p1 /mnt
% ll /mnt
total 28076
drwxrwxrwx 3 root wheel - 512 10月 9 04:32 ./
drwxr-xr-x 23 root wheel - 512 10月 8 23:22 ../
drwxrwxr-x 2 root operator - 512 10月 9 04:31 .snap/
-rwxr--r-- 1 griffon wheel - 22475540 10月 9 04:32 kabe-gami.zip*
-rwxr--r-- 1 griffon wheel - 6183181 10月 9 04:32 mikofuku_dd-dy_manual.pdf*
% df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada2p1 5061588 28072 4628592 1% /mnt
% sudo umount /mnt
% sudo gmirror label -v mirror0 ada2
Metadata value stored on ada2.
Done.
% gmirror insert -v mirror0 ada3
Done.
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2 (ACTIVE)
ada3 (ACTIVE)
% ll /dev/mirror/mirror0*
crw-r----- 1 root operator - 0x6b 10月 9 04:34 /dev/mirror/mirror0
% sudo mount /dev/mirror/mirror0 /mnt
mount: /dev/mirror/mirror0: Invalid argument
% gmirror list
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 1623628032
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368708608 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada2
Mediasize: 5368709120 (5.0G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 26546643
2. Name: ada3
Mediasize: 8589934592 (8.0G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 66523288
なんでマウントできない？と思ったら dmesg にこんなエラーが。GEOM_MIRROR: Device mirror/mirror0 launched (1/1).とりあえず gmirror destroy してから recover しておきましょう。
GEOM: mirror/mirror0: corrupt or invalid GPT detected.
GEOM: mirror/mirror0: GPT rejected -- may not be recoverable.
GEOM_MIRROR: Device mirror0: provider destroyed.
GEOM_MIRROR: Device mirror0 destroyed.
GEOM: ada2: the secondary GPT table is corrupt or invalid.
GEOM: ada2: using the primary only -- recovery suggested.
GEOM: diskid/DISK-01000000000000000001: the secondary GPT table is corrupt or invalid.
GEOM: diskid/DISK-01000000000000000001: using the primary only -- recovery suggested.
% gmirror destroy -v mirror0 Done. % gpart show ada2 => 40 10485680 ada2 GPT (5.0G) [CORRUPT]つまりこれか。
40 10485680 - free - (5.0G) % gpart recover ada2 ada2 recovered % gpart show ada2 => 40 10485680 ada2 GPT (5.0G) ←★CORRUPTがなくなった 40 10485680 - free - (5.0G)
FreeBSD Handbook
18. GEOM: Modular Disk Transformation Framework
18.3. RAID1 - Mirroring
18.3.1. Metadata Issues
> gmirror(8) stores one block of metadata at the end of the disk. Because GPT partition schemes also store metadata at the end of the disk, mirroring entire GPT disks with gmirror(8) is not recommended. MBR partitioning is used here because it only stores a partition table at the start of the disk and does not conflict with the mirror metadata.つまりは GPT ディスクにパーティション切ってそれをミラーすればいいというわけで。
(和訳) gmirror(8) は、ディスクの最後に 1ブロックのメタデータを保存します。GPT パーティションスキームはディスクの最後にメタデータも保存するため、 gmirror(8) で GPT ディスク全体をミラーリングすることはお勧めしません。MBR パーティショニングは、ディスクの先頭にのみパーティションテーブルを格納し、ミラーメタデータと競合しないため、ディスク全体を使用することが出来ます。
ここで注意する点は「両方同じパーティションテーブルを持ったパーティションが必要」ということだが、ぶっちゃけ後から追加するディスクが大きければ必ずしも同じパーティションテーブルでなくても良い。
仮にパーティションサイズが元居たパーティションサイズよりも小さい場合はこうなります。
% gpart show -lp ada2 ada3
=> 40 10485680 ada2 GPT (5.0G)
40 10485680 ada2p1 freebsd-ufs (5.0G)
=> 40 16777136 ada3 GPT (8.0G)
40 8388608 ada3p1 freebsd-ufs (4.0G)
8388648 8388528 - free - (4.0G)
% sudo gmirror label -v mirror0 ada2p1
Metadata value stored on ada2p1.
Done.
% gmirror insert -v mirror0 ada3p1
gmirror: Provider ada3p1 too small.
どうしてもパーティションサイズを同じにしてミラーしたいということであれば gpart backup [geom] | gpart restore [geom] してもいいが、ここで疑問なのは「ちょっとでも小さい方に restore したらどうなる？」だが、ちゃんと蹴られます。
% fdisk ada2
(省略)
start 63, size 10485657 (5119 Meg), flag 80 (active)
(省略)
% gpart show ada3
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
% gpart backup ada3 | gpart restore ada2
gpart: size '16777136': Invalid argument
gpart backup [geom] | gpart restore [geom] は、こう。
% gpart destroy -F ada4
ada4 destroyed
% gpart backup ada3 | gpart restore ada4
% gpart show ada3 ada4
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
=> 40 16777136 ada4 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
gpart backup | gpart destore はパーティション情報が残ってるとエラーになるので必ず gpart destroy でメタデータを削除してからにしましょう。gpart destroy で Device busy と怒られたら -F で強制的にデストローイ！！！
% gpart backup ada3 | gpart restore ada4
gpart: geom 'ada4': File exists
% gpart destroy ada4
gpart: Device busy
% gpart destroy -F ada4
ada4 destroyed
% gpart backup ada3 | gpart restore ada4
% gpart show ada3 ada4
=> 40 16777136 ada3 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
=> 40 16777136 ada4 GPT (8.0G)
40 16777136 1 freebsd-ufs (8.0G)
- NO COMMENT -
TrackBack URL:[編]
2019/10/06
gmirrorのディスクサイズを広げてみる(MBR)
ディスク容量の違うディスクを gmirror で使用し、その後大きなドライブを使ったときの対処法をここに残しておく。
想定している内容としては
順序としては
gpart resize の使い方については「[修正版] ディスクスペースを拡張してみる＠物理ディスク」を見て予習してください。
→ [修正版] ディスクスペースを拡張してみる＠物理ディスク
まずは RAID-1 メンバーの作成。
ディスクの確認。
中身があることを確認。
ここで「既存のディスクを RAID-1 化する」なら、現在使用中のディスクを先に gmirror で追加すること。
これを間違うと最悪ディスクの中身が消えます。
まずは中身が入ってるディスクをアタッチ。
ちなみにオプションは「停電またはシステムクラッシュの後に同期しない (-F)」としている。
(intel Rapid Strage Technorogy でも突然のリブートの後に同期するけど、あれをしないような感じ)
今度は小さいサイズの HDD を退役させ、ディスク容量を増やす。
次に新しいディスクを刺してリビルドを実施。
(ややこしいのでデバイス名は変えます。)
さてリサイズ。
リサイズは RAID-1 メンバーをマウントしたままでは操作できないのでシングルユーザーモードで起動してオフラインで行う。
まずは gmirror resize で RAID-1 メンバーの metadata を更新する。
これはオプション無しでやれば良きにはからってくれる。
次に gpart resize でパーティションを広げる。
これをやらないと広がりません。gmirror resize はあくまで metadata の更新のみのようだ。
ちょっと確認してみよう。
アンマウントは忘れずに。
あらかじめスライスとパーティションの中身を確認。
まずはスライスから。
まずは確認。
想定している内容としては
- ada2s1d に既にデータが存在する。
- RAID-1 としてペアにするディスクは ada2 より大きい物を使用する (ada3)。
- 後日その大きいサイズの HDD に容量を合わせる (ada2 = 5GB / ada3 = 8GB)。
順序としては
- マスターとなるディスク (小さい方) を gmirror label でメンバーに入れる。
- 大きいディスクを gmirror insert でメンバーに入れる。(この段階では小さいサイズに合う)
- 普通に (マルチユーザーモードで) 起動する。
- gmirror remove で小さいディスクをメンバーから外す。
- gmirror insert で新しいディスクをメンバーに入れる。
- 同期が完了するまで待つ。
- シングルユーザーモードで起動しなおす。
- gmirror resize で metadata を更新する。
- gpart resize でスライスとパーティションを広げる。
- growfs で広げたエリアを使えるようにする。
gpart resize の使い方については「[修正版] ディスクスペースを拡張してみる＠物理ディスク」を見て予習してください。
→ [修正版] ディスクスペースを拡張してみる＠物理ディスク
まずは RAID-1 メンバーの作成。
ディスクの確認。
% fdisk ada2
(省略)
start 63, size 10485657 (5119 Meg), flag 80 (active)
(省略)
% fdisk ada3
(省略)
start 63, size 16776522 (8191 Meg), flag 80 (active)
(省略)
ちゃんとサイズは違ってます。中身があることを確認。
% sudo mount /dev/ada2s1d /mnt % ll /mnt total 21996 drwxrwxrwx 3 root wheel - 512 10月 6 02:13 ./ drwxr-xr-x 23 root wheel - 512 10月 6 02:34 ../ drwxrwxr-x 2 root operator - 512 10月 6 02:12 .snap/ -rwxr--r-- 1 griffon wheel - 22475540 10月 6 02:13 kabe-gami.zip* % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ada2s1d 5061568 21992 4634652 0% /mntアンマウントしておく。
% sudo umount /mntRAID-1 メンバーの作成。
ここで「既存のディスクを RAID-1 化する」なら、現在使用中のディスクを先に gmirror で追加すること。
これを間違うと最悪ディスクの中身が消えます。
まずは中身が入ってるディスクをアタッチ。
ちなみにオプションは「停電またはシステムクラッシュの後に同期しない (-F)」としている。
(intel Rapid Strage Technorogy でも突然のリブートの後に同期するけど、あれをしないような感じ)
% sudo gmirror label -v -F mirror0 ada2 Metadata value stored on ada2. Done.念のためパーティションが存在するかを確認する。
% ll /dev/mirror/mirror0* crw-r----- 1 root operator - 0x68 10月 6 02:39 /dev/mirror/mirror0 crw-r----- 1 root operator - 0x69 10月 6 02:39 /dev/mirror/mirror0s1 crw-r----- 1 root operator - 0x6b 10月 6 02:39 /dev/mirror/mirror0s1d中身が無事かを確認する。
% sudo mount /dev/mirror/mirror0s1d /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/mirror0s1d 5061568 21992 4634652 0% /mnt % ll /mnt total 21996 drwxrwxrwx 3 root wheel - 512 10月 6 02:13 ./ drwxr-xr-x 23 root wheel - 512 10月 6 02:34 ../ drwxrwxr-x 2 root operator - 512 10月 6 02:12 .snap/ -rwxr--r-- 1 griffon wheel - 22475540 10月 6 02:13 kabe-gami.zip*この次に空のディスクをアタッチする。
% sudo gmirror insert -v mirror0 ada3
Done.
% gmirror status
Name Status Components
mirror/mirror0 DEGRADED ada2 (ACTIVE)
ada3 (SYNCHRONIZING, 55%)
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2 (ACTIVE)
ada3 (ACTIVE)
中身が無事かを確認する。% df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/mirror0s1d 5061568 21992 4634652 0% /mnt % ll /mnt total 21996 drwxrwxrwx 3 root wheel - 512 10月 6 02:13 ./ drwxr-xr-x 23 root wheel - 512 10月 6 02:34 ../ drwxrwxr-x 2 root operator - 512 10月 6 02:12 .snap/ -rwxr--r-- 1 griffon wheel - 22475540 10月 6 02:13 kabe-gami.zip*gmirror はディスクサイズが異なる物をペアにした場合、一番小さい物に合わせられる。
% gmirror list Geom name: mirror0 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NOFAILSYNC GenID: 0 SyncID: 1 ID: 414357605 Type: AUTOMATIC Providers: 1. Name: mirror/mirror0 Mediasize: 5368708608 (5.0G) ←★RAID-1 メンバーのサイズ Sectorsize: 512 Mode: r1w1e3 Consumers: 1. Name: ada2 Mediasize: 5368709120 (5.0G) ←★ディスクのサイズ Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3914746213 2. Name: ada3 Mediasize: 8589934592 (8.0G) ←★ディスクのサイズ Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 320096764ディスクサイズが異なっているが RAID-1 メンバーのサイズは一番小さい物に合わせられていることが確認出来る。
今度は小さいサイズの HDD を退役させ、ディスク容量を増やす。
% gmirror list
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NOFAILSYNC
GenID: 0
SyncID: 1
ID: 307285312
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368708608 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada2
Mediasize: 5368709120 (5.0G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 317673527
2. Name: ada3
Mediasize: 8589934592 (8.0G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 3541304040
% sudo gmirror remove mirror0 ada2 ←★サイズの小さいディスクを remove する。
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada3 (ACTIVE)
※ada2 (サイズの小さいディスク) が外れました。
% gmirror list
Geom name: mirror0
State: COMPLETE
Components: 1
Balance: load
Slice: 4096
Flags: NOFAILSYNC
GenID: 0
SyncID: 1
ID: 307285312
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368708608 (5.0G)
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada3
Mediasize: 8589934592 (8.0G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 3541304040
大きいサイズのディスクのみ残っていることを確認しておく。次に新しいディスクを刺してリビルドを実施。
(ややこしいのでデバイス名は変えます。)
% fdisk /dev/ada4
(省略)
start 63, size 16776522 (8191 Meg), flag 80 (active)
(省略)
こいつを RAID-1 メンバーにぶっこむ。
% sudo gmirror insert -v mirror0 ada4
Done.
% gmirror status
Name Status Components
mirror/mirror0 DEGRADED ada3 (ACTIVE)
ada4 (SYNCHRONIZING, 70%)
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada3 (ACTIVE)
ada4 (ACTIVE)
% gmirror list mirror0
Geom name: mirror0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NOFAILSYNC
GenID: 0
SyncID: 1
ID: 1256414995
Type: AUTOMATIC
Providers:
1. Name: mirror/mirror0
Mediasize: 5368708608 (5.0G) ←★RAID-1 メンバーのサイズ
Sectorsize: 512
Mode: r0w0e0
Consumers:
1. Name: ada3
Mediasize: 8589934592 (8.0G) ←★ディスクのサイズ
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 968255354
2. Name: ada4
Mediasize: 8589934592 (8.0G) ←★ディスクのサイズ
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 1
ID: 3468845043
この時点では過去の小さいサイズをひきずったままとなっている。さてリサイズ。
リサイズは RAID-1 メンバーをマウントしたままでは操作できないのでシングルユーザーモードで起動してオフラインで行う。
まずは gmirror resize で RAID-1 メンバーの metadata を更新する。
これはオプション無しでやれば良きにはからってくれる。
% sudo gmirror resize -v mirror0 Done. % gmirror list Geom name: mirror0 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NOFAILSYNC GenID: 0 SyncID: 1 ID: 2218697283 Type: AUTOMATIC Providers: 1. Name: mirror/mirror0 Mediasize: 8589934080 (8.0G) ←★RAID-1 メンバーのサイズが変わった Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ada3 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3801782773 2. Name: ada4 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3565686053広がりました。:)
次に gpart resize でパーティションを広げる。
これをやらないと広がりません。gmirror resize はあくまで metadata の更新のみのようだ。
ちょっと確認してみよう。
% sudo mount /dev/mirror/mirror0s1d /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/mirror0s1d 5061568 21992 4634652 0% /mnt↑ほらね。
アンマウントは忘れずに。
あらかじめスライスとパーティションの中身を確認。
% gpart show -lp /dev/mirror/mirror0
=> 63 16777152 mirror/mirror0 MBR (8.0G)
63 10485657 mirror/mirror0s1 freebsd-ufs [active] (5.0G)
10485720 6291495 - free - (3.0G)
% gpart show -lp /dev/mirror/mirror0s1
=> 0 10485657 mirror/mirror0s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 mirror/mirror0s1d freebsd-ufs (5.0G)
% gpart show /dev/mirror/mirror0
=> 63 16777152 mirror/mirror0 MBR (8.0G)
63 10485657 1 freebsd [active] (5.0G)
10485720 6291495 - free - (3.0G)
% gpart show /dev/mirror/mirror0s1
=> 0 10485657 mirror/mirror0s1 BSD (5.0G)
0 16 - free - (8.0K)
16 10485641 4 freebsd-ufs (5.0G)
広げていきます。まずはスライスから。
% sudo gpart resize -i 1 /dev/mirror/mirror0
mirror/mirror0s1 resized
% gpart show /dev/mirror/mirror0
=> 63 16777152 mirror/mirror0 MBR (8.0G)
63 16777152 1 freebsd [active] (8.0G)
次にパーティション。
% sudo gpart resize -i 4 /dev/mirror/mirror0s1
mirror/mirror0s1d resized
% gpart show /dev/mirror/mirror0s1
=> 0 16777152 mirror/mirror0s1 BSD (8.0G)
0 16 - free - (8.0K)
16 16777136 4 freebsd-ufs (8.0G)
growfs で広げた部分を使えるようにしよう。まずは確認。
% sudo growfs -N /dev/mirror/mirror0s1d super-block backups (for fsck_ffs -b #) at: 11542656, 12825152, 14107648, 15390144, 16672640本番。
% sudo growfs /dev/mirror/mirror0s1d It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/mirror/mirror0s1d from 5.0GB to 8.0GB? [yes/no] yes super-block backups (for fsck_ffs -b #) at: 11542656, 12825152, 14107648, 15390144, 16672640マウントしてみる。
% sudo mount /dev/mirror/mirror0s1d /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/mirror0s1d 8106676 21992 7436152 0% /mnt % ll /mnt total 21996 drwxrwxrwx 3 root wheel - 512 10月 6 03:34 ./ drwxr-xr-x 23 root wheel - 512 10月 6 03:55 ../ drwxrwxr-x 2 root operator - 512 10月 6 03:33 .snap/ -rwxr--r-- 1 griffon wheel - 22475540 10月 6 03:34 kabe-gami.zip*拡張終わり！！
- NO COMMENT -
TrackBack URL:[編]
[修正版] ディスクスペースを拡張してみる＠物理ディスク
前回日記で書いた「ディスクスペースを拡張してみる＠物理ディスク」だが、一部間違いがあったのでここに書き直す。
→ ディスクスペースを拡張してみる＠物理ディスク
ここでは「スライス自体が本来のディスクサイズよりも小さいもの」を対象に説明している。
つまりはこんな状態。
よくある例として、gmirror で小さいディスクに大きいディスクを使用した場合。
この場合、スライスの大きさそのものが小さくなっているので resize する時はスライスとパーティションの両方を resize する必要がある。
まずはスライスを大きくする。
今回は上の例だと、スライスを大きくする対象のインデックス番号は "freebsd [active] (5.0G)" の前にある "1" がそれなので -i 1 となる。
サイズ指定については gpart が増やせる最大値を勝手に判断するので特に指定する必要は無い。
次にパーティション。
ここで慌ててマウントしてもまだ容量は増えてません。
まずはテスト。
-N で増やせるかどうかを確認。
(そんなことは無いはずだけど…)
増やせることが確認出来たら -N を無くして実行。
増やしていいかい？」
と聞いてくるので、お祈りしながら "yes" を打ち込む。
これで拡張は完了だ。
→ ディスクスペースを拡張してみる＠物理ディスク
ここでは「スライス自体が本来のディスクサイズよりも小さいもの」を対象に説明している。
つまりはこんな状態。
% gpart show -lp ada3
=> 63 16777153 ada3 MBR (8.0G)
63 10485657 ada3s1 freebsd-ufs [active] (5.0G)
10485720 6291496 - free - (3.0G) ←★余ってる！
% gpart show -lp ada3s1
=> 0 10485657 ada3s1 BSD (5.0G) ←★余ってる！
0 16 - free - (8.0K)
16 10485641 ada3s1d freebsd-ufs (5.0G) ←★余ってる！
gpart show の -lp はスライス・パーティションをインデックス番号ではなくデバイスノード名 (ada3s1d とか) で表示する。よくある例として、gmirror で小さいディスクに大きいディスクを使用した場合。
この場合、スライスの大きさそのものが小さくなっているので resize する時はスライスとパーティションの両方を resize する必要がある。
まずはスライスを大きくする。
% gpart show -l ada3
=> 63 16777153 ada3 MBR (8.0G)
63 10485657 1 freebsd-ufs [active] (5.0G)
10485720 6291496 - free - (3.0G)
gpart resize でサイズを大きくするが、対象の選択はインデックス番号を使用する。今回は上の例だと、スライスを大きくする対象のインデックス番号は "freebsd [active] (5.0G)" の前にある "1" がそれなので -i 1 となる。
サイズ指定については gpart が増やせる最大値を勝手に判断するので特に指定する必要は無い。
% sudo gpart resize -i 1 ada3
ada3s1 resized
% gpart show -l ada3
=> 63 16777153 ada3 MBR (8.0G)
63 16777153 1 (null) [active] (8.0G)
大きくなりました :)次にパーティション。
% gpart show -l ada3s1
=> 0 16777153 ada3s1 BSD (8.0G)
0 16 - free - (8.0K)
16 10485641 4 freebsd-ufs (5.0G)
10485657 6291496 - free - (3.0G)
今度は "freebsd-ufs (5.0G)" の前にある "4" なので、-i 4 で指定する。
% sudo gpart resize -i 4 ada3s1
ada3s1d resized
% gpart show -l ada3s1
=> 0 16777153 ada3s1 BSD (8.0G)
0 16 - free - (8.0K)
16 16777137 4 freebsd-ufs (8.0G)
大きくなりました :)ここで慌ててマウントしてもまだ容量は増えてません。
% sudo mount /dev/ada3s1d /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ada3s1d 5061568 21992 4634652 0% /mnt増やした分は growfs で実際に使えるようにしなければならない。
まずはテスト。
-N で増やせるかどうかを確認。
% sudo growfs -N /dev/ada3s1d super-block backups (for fsck_ffs -b #) at: 11542656, 12825152, 14107648, 15390144, 16672640ここで
growfs: requested size **GB is not larger than the current filesystem size **GBとか出たら増やせないので諦めましょう。
(そんなことは無いはずだけど…)
増やせることが確認出来たら -N を無くして実行。
% sudo growfs /dev/ada3s1d It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/ada3s1d from 5.0GB to 8.0GB? [yes/no]「ファイルシステムを拡張する前にバックアップは取れよ！
増やしていいかい？」
と聞いてくるので、お祈りしながら "yes" を打ち込む。
% sudo growfs /dev/ada3s1d It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/ada3s1d from 5.0GB to 8.0GB? [yes/no] yes super-block backups (for fsck_ffs -b #) at: 11542656, 12825152, 14107648, 15390144, 16672640すると増やした部分のみ newfs される。
これで拡張は完了だ。
% sudo mount /dev/ada3s1d /mnt % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ada3s1d 8106676 21992 7436152 0% /mnt % ll /mnt total 21996 drwxrwxrwx 3 root wheel - 512 10月 6 02:13 ./ drwxr-xr-x 23 root wheel - 512 10月 6 02:34 ../ drwxrwxr-x 2 root operator - 512 10月 6 02:12 .snap/ -rwxr--r-- 1 griffon wheel - 22475540 10月 6 02:13 kabe-gami.zip*
- NO COMMENT -
TrackBack URL:[編]
2019/10/05
gmirrorの使い方
ぐぐってもイマイチぴんとこなかったのでまとめ。
■RAID グループから HDD を外したい
RAID グループ (ここでは mirror0) からなんらかの理由でディスクを外す必要があったら remove を使用する。
まずは状態確認。
新しいディスクを追加する場合は
rebuild で指定するディスクは「あとから追加した (現在 ACTIVE ではない) ディスク」を指定すること。
■gmirror insert 出来なかったら？
gmirror insert で新しいディスクを追加しようとしたら
■パーティショニングスキームにGPTを使ってるドライブでmirrorしたら中身が消えた！
慌てずgmirror destroyしてパーティションを指定してミラーを作りましょう。
■RAID グループから HDD を外したい
RAID グループ (ここでは mirror0) からなんらかの理由でディスクを外す必要があったら remove を使用する。
まずは状態確認。
% gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada1 (ACTIVE)
ada2 (ACTIVE)
mirror0 からディスクを外す。
% sudo gmirror remove mirror0 ada1
% sudo gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2 (ACTIVE)
※ada1 が消えた。
% sudo gmirror dump ada1
Can't read metadata from ada1: Invalid argument.
gmirror: Not fully done.
※ada1 に gmirror のメタデータが残っていないことを確認。
この状態では ada1 のディスクは ada2 と同期が取れているため、ぶっちゃけバックアップドライブとして保管しておいても良い。新しいディスクを追加する場合は
% sudo gmirror insert -v mirror0 ada1
Done.
sudo gmirror status
Name Status Components
mirror/mirror0 DEGRADED ada2 (ACTIVE)
ada1 (STALE)
追加した ada1 が STALE になっているので、ACTIVE な ada2 からデータを貰うことにする。
% sudo gmirror rebuild -v mirror0 ada1
Done.
% gmirror status
Name Status Components
mirror/mirror0 DEGRADED ada2 (ACTIVE)
ada1 (SYNCHRONIZING, 0%)
ここで注意する点は、指定するディスクを間違えないこと。rebuild で指定するディスクは「あとから追加した (現在 ACTIVE ではない) ディスク」を指定すること。
■gmirror insert 出来なかったら？
gmirror insert で新しいディスクを追加しようとしたら
gmirror: Not all disks connected.というエラーが出た場合は、落ち着いて forget を使用しよう。
% sudo gmirror forget -v mirror0
Done.
% sudo gmirror status
Name Status Components
mirror/mirror0 COMPLETE ada2 (ACTIVE)
これで新しいディスクを追加できるようになる。■パーティショニングスキームにGPTを使ってるドライブでmirrorしたら中身が消えた！
慌てずgmirror destroyしてパーティションを指定してミラーを作りましょう。
% sudo gmirror label -v mirror0 ada4p1
- NO COMMENT -
TrackBack URL:[編]
gmirroで組んでいたRAIDがクラッシュ
10月4日(金)の夜に特大の雷により瞬停、その影響でサーバーが再起動してしまったが、その後に gmirro の RAID-1 が勝手にリビルドしていた。
ここまではよかったのだが、不幸にもアクティブな HDD は不良セクタが発生してしまったディスクで、無事な HDD がリビルド対象になってしまっていた。
それに気がついたのがしばらくしてからだったので慌てて止めたが、途中でリビルドを止めたのでどこがどうなっているかわからないのが現状という状態。
予備の HDD は以前瞬停を食らったときに買ってきていた 1TB の HDD が有ったのでそれを使ったのだが、どうもその時に使った HDD で RAID-1 が組めない。
普通なら
更にはこの状態で
おかしいと思って
そこで、loader.conf で自動的にロードされている geom_mirror を一旦止めてシングルユーザーモードで起動。
するとなぜかメタデータが消えたので
あとは
この後は停電時の再起動で勝手にリビルドするのが困るので、
止まったかどうかについては
ちなみに新しいディスクを insert すると勝手にリビルドが始まるが、自身で rebuild を明示的に指示してリビルドを行う、つまり勝手にリビルドを行わせない場合は "-n" オプションを付ける。
ここまではよかったのだが、不幸にもアクティブな HDD は不良セクタが発生してしまったディスクで、無事な HDD がリビルド対象になってしまっていた。
それに気がついたのがしばらくしてからだったので慌てて止めたが、途中でリビルドを止めたのでどこがどうなっているかわからないのが現状という状態。
予備の HDD は以前瞬停を食らったときに買ってきていた 1TB の HDD が有ったのでそれを使ったのだが、どうもその時に使った HDD で RAID-1 が組めない。
普通なら
# sudo gmirror clear ada2とかすればメタデータを消去できるのだが今回はダメ。
更にはこの状態で
# gmirror label -v mirror0 ada1としても「mirror0 は既に使われてるで」とエラーが出て他の名前でしか組めない。
おかしいと思って
# gmirror dump ada1としてみると、どうも過去に gmirror で組んだ RAID-1 のメタデータが残ったままになっている。
そこで、loader.conf で自動的にロードされている geom_mirror を一旦止めてシングルユーザーモードで起動。
するとなぜかメタデータが消えたので
# gmirror load -vでモジュールをロードして
# gmirror label -v mirror0 ada1したら無事に RAID-1 を組む準備が出来た。
あとは
# gmirror insert -v mirror0 ada2でディスクを追加したら勝手にリビルドが始まるのでそのまま放置。
この後は停電時の再起動で勝手にリビルドするのが困るので、
# gmirror configure -F -v mirror0で勝手にリビルドするのを止める。
止まったかどうかについては
gmirror dump ada1
Metadata on ada1:
magic: GEOM::MIRROR
version: 4
name: mirror0
mid: 239193923
did: 779873358
all: 2
genid: 0
syncid: 1
priority: 0
slice: 4096
balance: load
mediasize: 500107861504
sectorsize: 512
syncoffset: 0
mflags: NOFAILSYNC
dflags: NONE
hcprovider:
provsize: 1000204886016
MD5 hash: 6ebcb89bc3fd056f5feda8878f2707ac
で確認出来る。ちなみに新しいディスクを insert すると勝手にリビルドが始まるが、自身で rebuild を明示的に指示してリビルドを行う、つまり勝手にリビルドを行わせない場合は "-n" オプションを付ける。
# gmirror configure -n -v mirror0
# gmirror dump ada1
(省略)
syncoffset: 0
mflags: NOAUTOSYNC
dflags: NONE
- NO COMMENT -
TrackBack URL:[編]
2018/09/30
ディスクスペースを拡張してみる＠VMware
VMware はディスクスペースを簡単に拡張できるが、拡張しても実際のディスクスペースは OS 側で拡張しなければならない。
# 拡張しないと「空きスペース」として扱われる。
★OS
cylinders が増えたことを確認する。
bsdlabel のオプションは -e (EDIT:編集) を使うこと。
間違って-w にしないように！！
やっちまうとパーティション情報がバラバラになるかもしれない。
一応単一パーティションだと問題はなかった (元通りにしたら中が見える) が、あまり良い事では無さそう。
d: にはその数値からオフセット分 (16) を引いた数値を指定。
この状態でも一応 mount は出来るが、まだ広げたところが使えないので 、広げた部分を newfs してくれる growfs を使う。
指定するデバイスは広げたパーティション。今回は /dev/ada3s1d。
念のためちゃんとバックアップは取っておきましょう。
# 拡張しないと「空きスペース」として扱われる。
★OS
% uname -a FreeBSD leviathan-vmw 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #0: Thu Sep 6 06:42:08 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386★拡張前
% fdisk ada3
******* Working on device /dev/ada3 *******
parameters extracted from in-core disklabel are:
cylinders=22192 heads=15 sectors/track=63 (945 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=22192 heads=15 sectors/track=63 (945 blks/cyl)
fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 20971377 (10239 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 687/ head 14/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
★VMwareで拡張後cylinders が増えたことを確認する。
% fdisk ada3
******* Working on device /dev/ada3 *******
parameters extracted from in-core disklabel are:
cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 20971377 (10239 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 687/ head 14/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
さて拡張作業。% sudo fdisk -u ada3 ******* Working on device /dev/ada3 ******* parameters extracted from in-core disklabel are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)この後が超重要。
↑★ここの cylinders と blks/cyl をかけ算する。44384x945=41942880 Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Do you want to change our idea of what BIOS thinks ? [n] ↑★リターン空打ちで[]内の返答となる Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 20971377 (10239 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 687/ head 14/ sector 63 Do you want to change it? [n] y ★パーティション1を編集する Supply a decimal value for "sysid (165=FreeBSD)" [165] Supply a decimal value for "start" [63] Supply a decimal value for "size" [20971377] 41942817
↑★計算した数字から start の 63 を引いた数字を入れる Explicitly specify beg/end address ? [n] sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41942817 (20479 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 351/ head 14/ sector 63 Are we happy with this entry? [n] y ★適用 The data for partition 2 is: <UNUSED> Do you want to change it? [n] The data for partition 3 is: <UNUSED> Do you want to change it? [n] The data for partition 4 is: <UNUSED> Do you want to change it? [n] Partition 1 is marked active Do you want to change the active partition? [n] We haven't changed the partition table yet. This is your last chance. parameters extracted from in-core disklabel are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41942817 (20479 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 351/ head 14/ sector 63 2: <UNUSED> 3: <UNUSED> 4: <UNUSED> Should we write new partition table? [n] y ★適用
bsdlabel のオプションは -e (EDIT:編集) を使うこと。
間違って-w にしないように！！
やっちまうとパーティション情報がバラバラになるかもしれない。
一応単一パーティションだと問題はなかった (元通りにしたら中が見える) が、あまり良い事では無さそう。
% sudo bsdlabel -e /dev/ada3s1 # /dev/ada3s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 20971377 0 unused 0 0 # "raw" part, don't edit d: 20971361 16 4.2BSD 0 0 0 ↓ # /dev/ada3s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 41942817 0 unused 0 0 # "raw" part, don't edit d: 41942801 16 4.2BSD 0 0 0c: には fdisk の size で入力した数値を指定。
d: にはその数値からオフセット分 (16) を引いた数値を指定。
この状態でも一応 mount は出来るが、まだ広げたところが使えないので 、広げた部分を newfs してくれる growfs を使う。
指定するデバイスは広げたパーティション。今回は /dev/ada3s1d。
% sudo growfs /dev/ada3s1d It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/ada3s1d from 10GB to 20GB? [yes/no] yes ←★ぶっ壊れる覚悟が出来たら "yes" で広げる。 super-block backups (for fsck_ffs -b #) at: 21802624, 23085120, 24367616, 25650112, 26932608, 28215104, 29497600, 30780096, 32062592, 33345088, 34627584, 35910080, 37192576, 38475072, 39757568, 41040064これで df すると容量が増えてる。
念のためちゃんとバックアップは取っておきましょう。
- NO COMMENT -
TrackBack URL:[編]
2018/09/24
Let's Encryptの証明書をapache 2.2にインストールするときのはまりどころ
ふと OpenSSL で証明書の検証がどうなってるかをチェックしてみた。
はい？
しかも Certificate chain が 1つしか出てこない。
おかしいと思ってぐぐってみると、どうも httpd-ssl.conf で SSLCertificateChainFile に中間証明書を指定しなければならないらしい。
というわけで
ちなみに Postfix は smtp_tls_CAfile に中間証明書を指定する。
proftpd は TLSCACertificateFile に中間証明書を指定する。
参考：
% openssl s_client -connect localhost:443 -showcerts < /dev/null
(省略)
Verify return code: 21 (unable to verify the first certificate)
はい？
しかも Certificate chain が 1つしか出てこない。
おかしいと思ってぐぐってみると、どうも httpd-ssl.conf で SSLCertificateChainFile に中間証明書を指定しなければならないらしい。
というわけで
SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/cert.pem"と指定して再起動してから openssl を叩いてみたら無事に "Verify return code: 0 (ok)" となった。
SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/chain.pem"
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/privkey.pem"
ちなみに Postfix は smtp_tls_CAfile に中間証明書を指定する。
proftpd は TLSCACertificateFile に中間証明書を指定する。
参考：
% openssl s_client -connect localhost:443 -showcerts < /dev/null % openssl s_client -connect localhost:25 -starttls smtp -showcerts < /dev/null % openssl s_client -connect localhost:110 -starttls pop3 -showcerts < /dev/null % openssl s_client -connect localhost:143 -starttls imap -showcerts < /dev/null
- NO COMMENT -
TrackBack URL:[編]
2018/09/22
certbot-autoの--pre-hookと--deploy-hookと--post-hook
こいつら微妙に違う。
共通して言えるのは「証明書の更新が必要な時に動く」こと。
たとえば証明書が複数有り……
使い分けとしては、証明書をサービスごと (例えば httpd と postfix と dovecot) に分けるのであれば、各サービスごとに deploy で証明書のコピーとプロセスの再起動を行えば良い。
pre と post はあまり使わないかも。
無理矢理使うのであれば、証明書の更新の際にメールを送るようにしたいとき、deploy で複数メールを送ると何通もメールが届くので、
なお、/etc/letsencrypt/renewal-hooks/ の下に pre、deploy、post ディレクトリがあるが、この中にスクリプトを入れておくとそれぞれのタイミングでそのディレクトリの中に有るスクリプトを実行してくれる。
また、オプションで --pre-hook、--deploy-hook、--post-hook により実行するスクリプトを指定出来るが、それらと /etc/letsencrypt/renewal-hooks/ の下に有る pre/deploy/post は共存可能である。
# どっちが先に実行されるかは不明なので順番を考慮しないようにしましょう。
deploy では
ただし FreeBSD の certbot (py27-certbot-0.25.1,1) では変数がセットされたりされなかったりと不安定だったので、RENEWED_LINEAGE については直打ちで対処しよう。
他には CERTBOT_* なんて環境変数もあるが、ろくに使えないので使わない方がいい。
特に CERTBOT_DOMAIN は証明書のコモンネームを保持していると思いきや、証明書で SANs を使うと一番最後にオーセンティケーターで承認したドメイン名が保存されているのでコモンネームと一致しない。
コモンネームを取得したいのであれば RENEWED_LINEAGE を / で区切った一番最後の文字列を取得すると良い。
共通して言えるのは「証明書の更新が必要な時に動く」こと。
| --pre-hook | 更新作業前に1度だけ実行 |
| --deploy-hook | 証明書ごとに実行 |
| --post-hook | 更新作業後に1度だけ実行 |
たとえば証明書が複数有り……
- 両方更新が無ければ何もせずに終了する。
- 1枚だけ更新があれば pre → deploy → post の順に実行される。
- 複数更新があれば pre → 複数回 deploy → post の順に実行される。
使い分けとしては、証明書をサービスごと (例えば httpd と postfix と dovecot) に分けるのであれば、各サービスごとに deploy で証明書のコピーとプロセスの再起動を行えば良い。
pre と post はあまり使わないかも。
無理矢理使うのであれば、証明書の更新の際にメールを送るようにしたいとき、deploy で複数メールを送ると何通もメールが届くので、
preで一時ファイルをクリアなんて方法がある。
↓
deployでRENEWED_DOMAINSやRENEWED_LINEAGEを追記モード (>>) で一時ファイルにリダイレクト
↓
postで一時ファイルをcatしてメールする
なお、/etc/letsencrypt/renewal-hooks/ の下に pre、deploy、post ディレクトリがあるが、この中にスクリプトを入れておくとそれぞれのタイミングでそのディレクトリの中に有るスクリプトを実行してくれる。
また、オプションで --pre-hook、--deploy-hook、--post-hook により実行するスクリプトを指定出来るが、それらと /etc/letsencrypt/renewal-hooks/ の下に有る pre/deploy/post は共存可能である。
# どっちが先に実行されるかは不明なので順番を考慮しないようにしましょう。
deploy では
RENEWED_DOMAINS：更新されたドメイン名の一覧 (半角スペース区切り)の環境変数が利用可能なので有効活用しよう。
RENEWED_LINEAGE：新しい証明書と暗号鍵を含む live サブディレクトリ名
ただし FreeBSD の certbot (py27-certbot-0.25.1,1) では変数がセットされたりされなかったりと不安定だったので、RENEWED_LINEAGE については直打ちで対処しよう。
他には CERTBOT_* なんて環境変数もあるが、ろくに使えないので使わない方がいい。
特に CERTBOT_DOMAIN は証明書のコモンネームを保持していると思いきや、証明書で SANs を使うと一番最後にオーセンティケーターで承認したドメイン名が保存されているのでコモンネームと一致しない。
コモンネームを取得したいのであれば RENEWED_LINEAGE を / で区切った一番最後の文字列を取得すると良い。
echo ${RENEWED_LINEAGE} | awk -F/ '{print $NF}'
- NO COMMENT -
TrackBack URL:[編]
2018/09/20
Let's Encryptでワイルドカード証明書を発行する その2
先日の日記で説明した --manual --preferred-challenges dns とフックスクリプトを使った Dynamc DNS による証明書取得だが、スクリプトを使わずとも --dns-rfc2136 を使えば Dynamic DNS による証明書の取得が出来るのでそれを使うことにする。
どうも CentOS では上手く行かなかったので「その1」を使用している。
こちら (その2) は FreeBSD 11.2-RELEASE p3 の
--dns-rfc2136 のドキュメント
→ Welcome to certbot-dns-rfc2136’s documentation!
やること
dnssec-keygen で Dynamic DNS 更新用の鍵を作成する。
アルゴリズムは HMAC-SHA512、キー名は "ac_gwnet" とした。
作った鍵は所有者以外みえないようにしておくように。
鍵ファイルは /etc/letsencrypt/ (FreeBSD の pkg で certbot をインストールしたら /usr/local/etc/letsencrypt/) の下にディレクトリを作り、その中に入れておくと良い。
# ちゃんと管理出来るならどこでもいい。
ゾーンの作成。
ACME Challenge 用ゾーン設定。Dynamic DNS なのでデフォルト TTL とネガティブキャッシュ TTL は短めに。
権限委譲設定。権限委譲元のゾーンに権限委譲先のドメイン名を書く。
DNS の準備が出来たら確認。
できれば受信側の DNS サーバーで named.log を tail しておくと良い。
テストし終えたら削除しておく。
証明書取得のための certbot 用設定ファイルの作成。
今回は certbot から Dynamic DNS の更新リクエストを DNS サーバーに投げるので、それ用の設定ファイルが必要。
[ /etc/letsencrypt/renewal-hooks/griffonworks.net.ini ]
※ファイル名は適当。
では証明書を取得してみる。
まずは --staging で！
参考：named.log (TXT レコードの登録時)
ステージングサイトからのドメイン名削除と本番機で反映をお忘れずに。
どうも CentOS では上手く行かなかったので「その1」を使用している。
こちら (その2) は FreeBSD 11.2-RELEASE p3 の
- py27-certbot-0.25.1,1
- py27-certbot-dns-rfc2136-0.25.1
--dns-rfc2136 のドキュメント
→ Welcome to certbot-dns-rfc2136’s documentation!
やること
- ACME Challenge 用 Dynamic DNS ゾーン (_acme-challenge.*) の作成
- Dynamic DNS 操作用鍵の作成
- certbot certonly --dns-rfc2136 の実行と renew
dnssec-keygen で Dynamic DNS 更新用の鍵を作成する。
アルゴリズムは HMAC-SHA512、キー名は "ac_gwnet" とした。
% dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 256 -n HOST ac_gwnet Kac_gwnet.+165+18145 % cat Kac_gwnet.+165+00000.key ac_gwnet. IN KEY 512 3 165 Dummy+Key+Strings=
作った鍵は所有者以外みえないようにしておくように。
% chmod 600 K*
鍵ファイルは /etc/letsencrypt/ (FreeBSD の pkg で certbot をインストールしたら /usr/local/etc/letsencrypt/) の下にディレクトリを作り、その中に入れておくと良い。
# ちゃんと管理出来るならどこでもいい。
ゾーンの作成。
% sudoedit named.conf # ACME Challenge 用 Dynamic DNS 操作鍵 key "ac_gwnet" { algorithm hmac-sha512; secret "Dummy+Key+Strings="; ← 作った鍵の中に書いてあるハッシュ値 }; # ACME Challenge 用 Dynamic DNS ゾーン zone "_acme-challenge.griffonworks.net" { type master; file "/var/named/dynamic/_acme-challenge_griffonworks_net.zone"; allow-update { localhost; key ac_gwnet; }; check-names ignore; allow-transfer { localhost; }; };
ACME Challenge 用ゾーン設定。Dynamic DNS なのでデフォルト TTL とネガティブキャッシュ TTL は短めに。
% /var/named/dynamic/_acme-challenge_griffonworks_net.zone $ORIGIN _acme-challenge.griffonworks.net. $TTL 60 @ IN SOA sakura.griffonworks.net. root.griffonworks.net. ( 20180920 3H 10M 1W 1M ) IN NS sakura.griffonworks.net.
権限委譲設定。権限委譲元のゾーンに権限委譲先のドメイン名を書く。
% /var/named/dynamic/griffonworks_net.zone (省略) _acme-challenge.griffonworks.net. IN NS sakura.griffonworks.net.
DNS の準備が出来たら確認。
できれば受信側の DNS サーバーで named.log を tail しておくと良い。
% nsupdate -k Kac_gwnet.+165+18145.key >server x.x.x.x ← DNSサーバーのアドレスを指定。localhost なら localhost。 >update add test._acme-challenge.griffonworks.net. 10 IN TXT "TestRecord" >send % digna +noall +ans +ques TXT test._acme-challenge.griffonworks.net. ;test._acme-challenge.griffonworks.net. IN TXT test._acme-challenge.griffonworks.net. 10 IN TXT "TestRecord" ←登録出来た
テストし終えたら削除しておく。
% nsupdate -k Kac_gwnet.+165+18145.key >server x.x.x.x ← DNSサーバーのアドレスを指定。localhost なら localhost。 >update delete test._acme-challenge.griffonworks.net. >send % digna +noall +ans +ques TXT test._acme-challenge.griffonworks.net. ;test._acme-challenge.griffonworks.net. IN TXT
証明書取得のための certbot 用設定ファイルの作成。
今回は certbot から Dynamic DNS の更新リクエストを DNS サーバーに投げるので、それ用の設定ファイルが必要。
[ /etc/letsencrypt/renewal-hooks/griffonworks.net.ini ]
※ファイル名は適当。
# Target DNS server : Dynamic DNSの更新リクエストを投げる先のDNSサーバーアドレス dns_rfc2136_server = x.x.x.x # Target DNS port dns_rfc2136_port = 53 # TSIG key name : 鍵で使用したキー名 dns_rfc2136_name = ac_gwnet # TSIG key secret : 鍵の中に書かれているハッシュ値 dns_rfc2136_secret = Dummy+Key+Strings= # TSIG key algorithm : 鍵を作るときに使用したアルゴリズム dns_rfc2136_algorithm = HMAC-SHA512
では証明書を取得してみる。
まずは --staging で！
% sudo certbot certonly -m griffon@griffonworks.net --staging \ -d griffonworks.net \ --manual-public-ip-logging-ok \ --dns-rfc2136 \ --dns-rfc2136-credentials /usr/local/etc/letsencrypt/renewal-hooks/griffonworks.net.ini \ --force-renewal \ --dns-rfc2136-propagation-seconds 10オプションの一部を説明。
- 証明書証明リクエストの認証方式にダイナミックDNS更新を利用する (--dns-rfc2136)
- ダイナミックDNS更新利用時の設定ファイル (--dns-rfc2136-credentials)
- ACME サーバーが DNS を参照するまでの待ち時間 (--dns-rfc2136-propagation-seconds)。DNS更新が早いならば短くして良い。
% sudo certbot certonly (省略) Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator dns-rfc2136, Installer None Obtaining a new certificate Performing the following challenges: dns-01 challenge for griffonworks.net Waiting 10 seconds for DNS changes to propagate Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /usr/local/etc/letsencrypt/live/griffonworks.net/fullchain.pem Your key file has been saved at: /usr/local/etc/letsencrypt/live/griffonworks.net/privkey.pem Your cert will expire on 2018-12-19. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew"もし Dynamic DNS 更新に失敗したら "PluginError: Received response from server: REFUSED" と言われるので、鍵情報が間違ってないかなどを確認しよう。
参考：named.log (TXT レコードの登録時)
20-Sep-2018 13:25:26.982 update-security: client 219.75.232.51#62490: signer "certbot" approved参考：named.log (TXT レコードのクリーンナップ時)
20-Sep-2018 13:25:26.982 update: client 219.75.232.51#62490: updating zone '_acme-challenge.griffonworks.net/IN': adding an RR at '_acme-challenge.griffonworks.net' TXT
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_timer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_maintenance: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.673 update-security: client 219.75.232.51#62492: signer "certbot" approved成功したらあとは certbot renew --cert-name [CN名] で証明書の更新を行う。
20-Sep-2018 13:25:35.673 update: client 219.75.232.51#62492: updating zone '_acme-challenge.griffonworks.net/IN': deleting an RR at _acme-challenge.griffonworks.net TXT
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_timer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_maintenance: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
ステージングサイトからのドメイン名削除と本番機で反映をお忘れずに。
- NO COMMENT -
TrackBack URL:[編]
2018/09/19
MewとTLS(STARTTLS)とSSL(SMTP over SSL)と
超どはまりした。
6、7時間くらいは失ったんじゃないかな？orz
先に結論を書くと、ちゃんと Mew のマニュアルには書いてあるのだが TLS/SSL という用語がプロトコルの違いだと勘違いしていたのがそもそもの始まりでして。
こういうややこしいのは TLS/SSL とか書かないで欲しいんだけど！
→ 9.4 Secure Socket Layer
→ 9.5 Transport Layer Security
→ SSL と TLS と STARTTLS の違い
事の始まりは .mew.el を触って SMTP 送信しようとしたら "Creating an SSL/TLS connection..." で刺さって帰ってこなくなったので調査開始。
.mew.el に
すると "Creating an SSL/TLS connection..." で刺さるので C-g で中止してから C-x b で *Mew debug* を表示させる。
# ちなみに元に戻るにはもう一度 C-x b したら "Switch to buffer (default %inbox):" と聞いてくるのでそのままリターンで Mew に戻れる。
stunnel を使っているので stunnel が利用する一時設定ファイルは /tmp/ に作られる。
こっちもちょっと確認する。
[ (smtp-port . 587) ]
んんん？TCP-465？SMTP over SSL？TCP-587を指定してるのに？
一旦 Mew を終了。
なお、送信失敗したメールは +queue に溜まるので C-u C-c C-c で再送できるので、刺さり続けるならば新規メールを作る必要は無い。
[ (smtp-ssl-port . 587) ]
今度はちゃんと TCP-587 で繋がってるけど "unknown protocol" で接続出来ん。
というか SSLv2/SSLv3？TLSv1 じゃなくて？
一旦 Mew を終了。
らちが明かないのでバックアップの .mew.el を書き戻すと繋がった。
何がおかしいのかと比較してみたら smtp-port と smtp-ssl-port が両方指定されていたので疑問に思いつつ。
[ (smtp-port . 587) と (smtp-ssl-port . 587) ]
"protocol=smtp" が増えてるって事は…… smtp-ssl-port だけの時の動作不良は opens s_client で -starttls したときにプロトコルを指定しなかったときの動作を同じか。
というわけで冒頭の結果に至る。
STARTTLS を使用するときは smtp-ssl-port と smtp-port の両方を指定しましょう。
Mew でサーバ証明書 (CRT) の検証をする場合。
必要な証明書はルート証明書であり中間証明書 (Let's Encrypt は中間証明機関) は不要。
証明書が Mew を使うサーバーに有る場合は mew-ssl-cert-directory で証明書を保存しているディレクトリを指定する。
# サーバー管理者は http://www.mew.org/Release/certs-*.tar.gz をダウンロードし、鯖の公開出来るようなディレクトリで公開すると良い。
どの証明書を使うかは、鯖で使っている証明書の証明機関がどこかによって変わる。
例えば Let's Encrypt なら、Lets の証明書を見てみるとルート証明機関は "DST Root CA X3" なので、この証明機関の CRT 証明書を入手する。
# Windows 使いなら IE から "Base64 encoded X.509 (.CER)" で、Firefox なら "X.509 証明書 (PEM)" で証明書をエクスポートすると良い。
ファイル名に法則が有り、以下のようにファイル名を決める。
openssl x509 -hash で出てきた文字列＋".0" をファイル名とする。
6、7時間くらいは失ったんじゃないかな？orz
先に結論を書くと、ちゃんと Mew のマニュアルには書いてあるのだが TLS/SSL という用語がプロトコルの違いだと勘違いしていたのがそもそもの始まりでして。
TLS = STARTTLSということに気がついたのが深夜 3時。
SSL = SMTP over SSL
こういうややこしいのは TLS/SSL とか書かないで欲しいんだけど！
→ 9.4 Secure Socket Layer
→ 9.5 Transport Layer Security
→ SSL と TLS と STARTTLS の違い
事の始まりは .mew.el を触って SMTP 送信しようとしたら "Creating an SSL/TLS connection..." で刺さって帰ってこなくなったので調査開始。
.mew.el に
(setq mew-debug t)を書いてメールを送信する。
すると "Creating an SSL/TLS connection..." で刺さるので C-g で中止してから C-x b で *Mew debug* を表示させる。
# ちなみに元に戻るにはもう一度 C-x b したら "Switch to buffer (default %inbox):" と聞いてくるのでそのままリターンで Mew に戻れる。
stunnel を使っているので stunnel が利用する一時設定ファイルは /tmp/ に作られる。
こっちもちょっと確認する。
[ (smtp-port . 587) ]
<SSL/TLS: > 2018.09.19 03:29:39 LOG3[0]: s_connect: connect 153.126.183.190:465: Connection refused (61) % cat /tmp/griffon22650KWU/mew226506hM client=yes pid= verify=0 foreground=yes debug=debug libwrap=no syslog=no CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/ CAfile=/usr/local/share/certs/ca-root-nss.crt [11337] accept=127.0.0.1:11337 connect=mail.griffonworks.net:465"Creating an SSL/TLS connection..." で刺さる。
んんん？TCP-465？SMTP over SSL？TCP-587を指定してるのに？
一旦 Mew を終了。
なお、送信失敗したメールは +queue に溜まるので C-u C-c C-c で再送できるので、刺さり続けるならば新規メールを作る必要は無い。
[ (smtp-ssl-port . 587) ]
<SSL/TLS: > 2018.09.19 03:34:14 LOG5[0]: s_connect: connected 153.126.183.190:587"Creating an SSL/TLS connection..." で刺さる。
<SSL/TLS: > 2018.09.19 03:34:14 LOG3[0]: SSL_connect: 140770FC: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
<SSL/TLS: > 2018.09.19 03:34:14 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.09.19 03:34:14 LOG7[0]: Deallocating application specific data for session connect address 2018.09.19 03:34:14 LOG7[0]: Remote descriptor (FD=7) closed 2018.09.19 03:34:14 LOG7[0]: Local descriptor (FD=3) closed 2018.09.19 03:34:14 LOG7[0]: Service [11065] finished (0 left) % cat /tmp/griffon22698wWU/mew22698giM client=yes pid= verify=0 foreground=yes debug=debug libwrap=no syslog=no CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/ CAfile=/usr/local/share/certs/ca-root-nss.crt [11385] accept=127.0.0.1:11385 connect=mail.griffonworks.net:587
今度はちゃんと TCP-587 で繋がってるけど "unknown protocol" で接続出来ん。
というか SSLv2/SSLv3？TLSv1 じゃなくて？
一旦 Mew を終了。
らちが明かないのでバックアップの .mew.el を書き戻すと繋がった。
何がおかしいのかと比較してみたら smtp-port と smtp-ssl-port が両方指定されていたので疑問に思いつつ。
[ (smtp-port . 587) と (smtp-ssl-port . 587) ]
<SSL/TLS: > 2018.09.19 03:37:20 LOG5[0]: s_connect: connected 153.126.183.190:587お、"SMTP LOGIN password (griffon):" でパスワード聞いてきた。
<SSL/TLS: > 2018.09.19 03:37:20 LOG5[0]: Service [11442] connected remote server from 192.168.1.10:62152
2018.09.19 03:37:20 LOG7[0]: Setting remote socket options (FD=7) 2018.09.19 03:37:20 LOG7[0]: Option TCP_NODELAY set on remote socket 2018.09.19 03:37:20 LOG7[0]: Remote descriptor (FD=7) initialized <SSL/TLS: > 2018.09.19 03:37:20 LOG7[0]: <- 220 sakura.griffonworks.net ESMTP Postfix 2018.09.19 03:37:20 LOG7[0]: -> 220 sakura.griffonworks.net ESMTP Postfix % cat /tmp/griffon22755fXU/mew22755PjM client=yes pid= verify=0 foreground=yes debug=debug libwrap=no syslog=no CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/ CAfile=/usr/local/share/certs/ca-root-nss.crt [11442] accept=127.0.0.1:11442 connect=mail.griffonworks.net:587
protocol=smtp
"protocol=smtp" が増えてるって事は…… smtp-ssl-port だけの時の動作不良は opens s_client で -starttls したときにプロトコルを指定しなかったときの動作を同じか。
というわけで冒頭の結果に至る。
STARTTLS を使用するときは smtp-ssl-port と smtp-port の両方を指定しましょう。
Mew でサーバ証明書 (CRT) の検証をする場合。
必要な証明書はルート証明書であり中間証明書 (Let's Encrypt は中間証明機関) は不要。
証明書が Mew を使うサーバーに有る場合は mew-ssl-cert-directory で証明書を保存しているディレクトリを指定する。
# サーバー管理者は http://www.mew.org/Release/certs-*.tar.gz をダウンロードし、鯖の公開出来るようなディレクトリで公開すると良い。
例)無い場合は ~/.certs/ にルート証明書を置く。
(setq mew-ssl-cert-directory "/usr/local/share/certs")
どの証明書を使うかは、鯖で使っている証明書の証明機関がどこかによって変わる。
例えば Let's Encrypt なら、Lets の証明書を見てみるとルート証明機関は "DST Root CA X3" なので、この証明機関の CRT 証明書を入手する。
# Windows 使いなら IE から "Base64 encoded X.509 (.CER)" で、Firefox なら "X.509 証明書 (PEM)" で証明書をエクスポートすると良い。
ファイル名に法則が有り、以下のようにファイル名を決める。
openssl x509 -hash で出てきた文字列＋".0" をファイル名とする。
% openssl x509 -hash -noout -in ./.certs/cafile.crt 2e5ac55d.0 % mv cafile.crt 2e5ac55d.0.0面倒臭かったら mew-config-alist の中で
; 証明書を検証しないとしてもいいけどフェイクサイトかどうか判断出来ないのであまりよろしくはない。
(ssl-verify-level . 0)
- 安田幸子：他に連絡先が見つかりませんでしたのでコメント欄から失礼いたします。以前イギリスのデジタルマーケティング会社の要請で記事コラボレーションのご依頼についてご連絡させていただきました。この度プロジェクト内容に変更があり、謝礼金も大幅に増額されましたので、貴サイトのように信頼あるサイトで再検討して頂きたくご連絡しております。当方クライアント指定のキーワードを使って、指定ウェブページにリンクする記事執筆或いは既存記事への追記というのがご依頼の内容でございます。こちらのサイトの主旨に背かない範囲でのお願いです。そのようなご依頼に対する対応は可能でしょうか。特定商品の宣伝ではない、一般的な文です。もしよろしければ弊社並びにクライアント情報、新しい謝礼金も含めまして詳細についてメールでご説明させて下さい。どうぞよろしくお願いいたします。sachikoyasuda1604@gmail.com
- Ｇ兄：そのような案件はお受けしておりませんのでよろしくお願いします。
TrackBack URL:[編]
2018/09/17
MewでSSL over POP3/SMTPが使えなくなった
さくらのVPSにメール機能を集約するため、POP3 と SMTP の SSL 化を実施。
代表的なメーラー (Thunderbird、秀丸メール、電信八号) で送受信できたので Mew で…と思ったらなんかつながらない。
結論から言うと
.mew.el に次の1行を書いてログ記録モードにする。
ささったら C-g して止めてから C-x b で *Mew debug* を見る
すると
# ちなみに接続先は SSLv3 をサポートしてません。
こんどはどうだ？と思ったらまだ刺さる。
とりあえず stunnel が更新されてないかを見てみると stunnel 5.49 があったのでビルド→インストール。
すると刺さりはしなかったがエラーになったので *Mew debug* を見てみると stunnel のヘルプが出ていた。
stunnel のバージョン表示したらなんかわかるかな？と思って表示してみたら
Mew で stunnel 5系が使えないのでちょっとぐぐってみると、どうやらバージョンアップが必要なようなので Mew 6.8 を落としてきてビルド→インストール。
そして実行してみると無事 SSL over POP3/SMTP が実行できたとさ。
代表的なメーラー (Thunderbird、秀丸メール、電信八号) で送受信できたので Mew で…と思ったらなんかつながらない。
Creating an SSL/TLS connection...と出たきり刺さって帰ってこないので C-g で殺す。
結論から言うと
- stunnel がリンクしてる OpenSSL が古い (SSLv3 で繋ぎに行ってる可能性)
- stunnel が使う chipher がサポートされていない (FIPS なんちゃらのエラー)
- Mew が新しい stunnel をサポートしていない
.mew.el に次の1行を書いてログ記録モードにする。
(setq mew-debug t)これで mew を起動し、"i" でメールを取り込む。
ささったら C-g して止めてから C-x b で *Mew debug* を見る
すると
<SSL/TLS: >SSLv3 でアクセスしてる…って、stunnel がリンクしてる OpenSSL のライブラリが古いままだったようなのでビルドし直す。
2018.09.17 01:12:07 LOG3[42074:676788736]: SSL_connect: 14094410: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failurer
# ちなみに接続先は SSLv3 をサポートしてません。
こんどはどうだ？と思ったらまだ刺さる。
<SSL/TLS: >うーん、これは流石に原因がわかるまでに時間がかかった。
Reading configuration from file /tmp/griffon59303mzo/mew59303x_X
FIPS_mode_set: F06D065: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported
とりあえず stunnel が更新されてないかを見てみると stunnel 5.49 があったのでビルド→インストール。
すると刺さりはしなかったがエラーになったので *Mew debug* を見てみると stunnel のヘルプが出ていた。
stunnel のバージョン表示したらなんかわかるかな？と思って表示してみたら
/usr/source/stunnel-4.34% stunnel -version stunnel 4.34 on i386-unknown-freebsd8.0 with OpenSSL 1.0.2p 14 Aug 2018 : : Service-level options cert = /usr/local/etc/stunnel/stunnel.pem ciphers = FIPS
curve = sect163r2
/usr/source/stunnel-5.49% stunnel -version stunnel 5.49 on i386-unknown-freebsd8.0 platform : : Service-level options: ciphers = FIPS (with "fips = yes") ciphers = HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK (with "fips = no")あぁ、chipherが対応してなかったのか〜というわけで問題は Mew。
curve = prime256v1
Mew で stunnel 5系が使えないのでちょっとぐぐってみると、どうやらバージョンアップが必要なようなので Mew 6.8 を落としてきてビルド→インストール。
そして実行してみると無事 SSL over POP3/SMTP が実行できたとさ。
- NO COMMENT -
TrackBack URL:[編]
2018/09/16
Let's Encryptでワイルドカード証明書を発行する
今回は「さくらのVPS」で Linux OS (CentOS - RedHat6 final) を使っているということもあり、certbot-auto が使えてます。
え？今まではどうやってるのかって？
手動でやってんだよ！！！！
マジクソ面倒臭い。
でも certbot-auto にしても微妙に面倒臭いのは変わりない。
意外と楽でした。
と、その前に。
証明書をインストールしたはいいが、不正な証明書だと言われたら cert.pem から fullchain.pem に変更しよう。
というか fullchain.pem の方がなにかと良い結果になる。
これは OS やブラウザに Let's Encrypt の中間証明書が入っていないのが原因なので、証明書に中間証明書を混ぜ込んでしまう。
# 今回は K-9 Mail でおおはまり。
結論から言うと「Amazon Route53 使ってるならワイルドカードの自動更新は (説明が多いから) 簡単だけど、他の DNS を使ってるならば「どうやればいいのか」を探すところから始めなければならないのでとても面倒くさい。
# 一応、認証方式に Dynamic DNS を使った更新 (certonly → --dns-rfc2136) は有る。
もうワイルドカード使わずに webroot のオーセンティケーター (Apache の Web 型承認) でいいんじゃね？と思う次第。
まずは基本。
certbot-auto に勝手に証明書をインストールさせないために、サブコマンドは "certonly" を使用すること。
このサブコマンドは証明書を発行して貰いサーバーの /etc/letsencrypt/ に保存するだけのコマンド。
install とか run とか使うとどこかにインストールされてしまうので注意。
httpd が起動している Web サーバーで証明書を発行してみよう。
# 説明ではそうなってるし。
複数のドメインを含めるならば -w -d -w -d … と続く。
本番機に何度もリクエストを投げるとアクセス制限を食らうので、使い方がよくわからないな〜という人や動きを確認したいだけならば --staging を付けて実行。
これは制限の緩いテスト環境 (conf ファイルでは server = https://acme-staging-v02.api.letsencrypt.org/directory の 1行がある) を使用するオプション。
certbot-auto の使い方は「Let's Encrypt ユーザーガイド」を参照すること。
「コマンド解説（コマンドリファレンス）」は旧式の使い方なので、参考にはなるけど増えてるオプションの解説が無い。
まず前提条件。
ワイルドカードとネイキッドドメインのホスト名部は別扱いになる。つまり
なので *.example.com の証明書を発行しても example.com の証明書にはならないということ。
# *.example.com だけの証明書を持つサーバーに example.com でアクセスすると不正な証明書になる。
# example.com が記述されていないので当然ではあるが。
テストをする際は最新の certbot-auto だと ACME v2 に対応しているので
例)
本番で使ってるなら気をつけてね！！
ここで重要なのは
--staging を着けるとテストモードになる。
なんでテストをするのかって？
ちゃんと証明書の発行が出来るか、更新が出来るかを確認するために。
本番環境では証明書発行・更新の回数制限があるので要注意。
なおテストモードは制限がかなり緩い。
詳しくはこちらを。
制限と仕様からLet's Encrypt(ACMEv1)の話
更新するときは certbot-auto renew を実行。
これだけ。すごいかんたん。
証明書の更新時期が来てなければ certbot-auto が勝手に判断して更新せずに終了。
えらい。
cron に登録しておこう。
なお、1つのサーバー上で複数の証明書を管理している場合は --cert-name で CN の名前を指定すると良い。
例)
/etc/letsencrypt/ のディレクトリに証明書が格納されている各ディレクトリ名がそれ。
本番環境で作成した証明書を消す場合は、Lets Encrypt サーバーに置いてある履歴を消す必要があるので revoke 処理を行う。
ステージング環境を使用した場合は必ず --staging を付けること。
消さなくても期限が超えたら消えると思う…。
オーセンティケーターに --manual を選んだとき、ドメイン使用権の認証方式に DNS 認証を使うならば "--preferred-challenges dns" を着ける。
(デフォルトは http)
さて、自ドメインにサブドメイン切って --preferred-challenges dns による自動更新を行ってみる。
参考にしたのは
Certbotによるワイルドカード証明書と自動更新の設定
だが、dns-01 スクリプトの書式に間違いがあったので修正している。
# nsupdate に渡すコマンドの先頭に update の記述が無いので "delete メソッドなんぞ知らぬ！" と怒られる。
まずは Dynamic DNS の準備。
Dynamic DNS のゾーンは分けておかないと元のゾーンが Dynamic DNS によりぐちゃぐちゃにされるのでちゃんと分ける。
以下のように親のゾーンである griffonworks.net. から権限委譲して別ファイルにすると良い。
TSIG 鍵は nsupdate -l で運用する (ローカルホスト限定) ので今のところは不要。
[ /etc/named.conf ]
ちゃんと
今度は certbot-auto。
まずは前準備としてフック用のスクリプトを用意。
参考：certbot User Guide - Pre and Post Validation Hooks
実行属性は付けておいてください。
オーナーはてきとー。
[ /etc/letsencrypt/renewal-hooks/dns-01-auth.sh ]
ちゃんとステージング環境 (--staging) で試しましょう。
スクリプトで何をやってるか気になるなら nsupdate -l にパイプしてる内容を一時ファイルに書き出し、一時ファイルを nsupdate に喰わせるスクリプトに変更して、一時ファイルを cat してみると良い。
普段は renew を実行するだけで良い。
ちなみに "Issuer: CN=Fake LE Intermediate X1" はステージング環境のこと。
本番だと "Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" になる。
いろいろお試しが終わったら revoke しておきましょう。
なお、ネイキッドドメインの DNS 認証については、先に紹介したい「Certbotによるワイルドカード証明書と自動更新の設定」の開設で _acme-challenge ゾーンを個別に切って (権限委譲で分離) Dynamic DNS ゾーンにすることで対応出来た。
え？今まではどうやってるのかって？
手動でやってんだよ！！！！
マジクソ面倒臭い。
と、その前に。
証明書をインストールしたはいいが、不正な証明書だと言われたら cert.pem から fullchain.pem に変更しよう。
というか fullchain.pem の方がなにかと良い結果になる。
これは OS やブラウザに Let's Encrypt の中間証明書が入っていないのが原因なので、証明書に中間証明書を混ぜ込んでしまう。
# 今回は K-9 Mail でおおはまり。
結論から言うと「Amazon Route53 使ってるならワイルドカードの自動更新は (説明が多いから) 簡単だけど、他の DNS を使ってるならば「どうやればいいのか」を探すところから始めなければならないのでとても面倒くさい。
# 一応、認証方式に Dynamic DNS を使った更新 (certonly → --dns-rfc2136) は有る。
もうワイルドカード使わずに webroot のオーセンティケーター (Apache の Web 型承認) でいいんじゃね？と思う次第。
まずは基本。
- -m は忘れずに！(期限が近づいてきたらメールで知らせてくれる)
- 指定した基本的なオプションは conf ファイルに保存される。--staging や --post-hook なども全て。ただし revoke の時は --staging は付ける必要有り。どんなオプションが保存されているかは /etc/letsencrypt/renewal/*.conf を見よう。
- 更新は certbot-auto renew と叩くだけ。あとは certbot-auto が良きに計らってくれる。複数のドメインを別の証明書で作った場合は --cert-name で CN の名前を指定する。
- 使い終わった証明書はステージング環境であっても revoke しておこう。まぁ期限が来たら勝手に消えると思うけど。
certbot-auto に勝手に証明書をインストールさせないために、サブコマンドは "certonly" を使用すること。
このサブコマンドは証明書を発行して貰いサーバーの /etc/letsencrypt/ に保存するだけのコマンド。
install とか run とか使うとどこかにインストールされてしまうので注意。
httpd が起動している Web サーバーで証明書を発行してみよう。
% sudo certbot-auto certonly --webroot \
-m [自分のメールアドレス] \
-w [ホスト名に対するディレクトリルート] \
-d ホスト名 \
--manual-public-ip-logging-ok
例)
% sudo certbot-auto certonly --webroot \
-m [自分のメールアドレス] \
-w /home/www/defaultroot/public_html/ \
-d www.example.com \
-w /home/www/test/public_html/ \
-d test.example.com \
--manual-public-ip-logging-ok
オプションの順序は関係ないと思うけど、オーセンティケーターに webroot を使うなら -w を先に書いて -d は後ろに書いた方がいいかもしれない。# 説明ではそうなってるし。
複数のドメインを含めるならば -w -d -w -d … と続く。
本番機に何度もリクエストを投げるとアクセス制限を食らうので、使い方がよくわからないな〜という人や動きを確認したいだけならば --staging を付けて実行。
これは制限の緩いテスト環境 (conf ファイルでは server = https://acme-staging-v02.api.letsencrypt.org/directory の 1行がある) を使用するオプション。
certbot-auto の使い方は「Let's Encrypt ユーザーガイド」を参照すること。
「コマンド解説（コマンドリファレンス）」は旧式の使い方なので、参考にはなるけど増えてるオプションの解説が無い。
まず前提条件。
ワイルドカードとネイキッドドメインのホスト名部は別扱いになる。つまり
example.com ≠ *.example.comとなる。
なので *.example.com の証明書を発行しても example.com の証明書にはならないということ。
# *.example.com だけの証明書を持つサーバーに example.com でアクセスすると不正な証明書になる。
# example.com が記述されていないので当然ではあるが。
テストをする際は最新の certbot-auto だと ACME v2 に対応しているので
% sudo certbot-auto certonly --manual --staging \
-m [メールアドレス] -d "*.自ドメイン" \
--manual-public-ip-logging-ok --force-renewal
でテスト可能。例)
% sudo certbot-auto certonly --manual --staging \
-m [メールアドレス] -d "*.example.com" \
--manual-public-ip-logging-ok --force-renewal
説明。- オーセンティケーターは手動 (--manual)
- ステージング環境を使用する (--staging)
- グローバルIPアドレスを認証局でロギングすることに対する確認を表示しない (--manual-public-ip-logging-ok)
- 期限が残っていようが問答無用で再発行する (--force-renewal)
本番で使ってるなら気をつけてね！！
ここで重要なのは
なんでテストをするのかって？
ちゃんと証明書の発行が出来るか、更新が出来るかを確認するために。
本番環境では証明書発行・更新の回数制限があるので要注意。
なおテストモードは制限がかなり緩い。
詳しくはこちらを。
制限と仕様からLet's Encrypt(ACMEv1)の話
更新するときは certbot-auto renew を実行。
これだけ。すごいかんたん。
証明書の更新時期が来てなければ certbot-auto が勝手に判断して更新せずに終了。
えらい。
cron に登録しておこう。
なお、1つのサーバー上で複数の証明書を管理している場合は --cert-name で CN の名前を指定すると良い。
例)
% sudo certbot-auto renew --cert-name 2nd.example.comCN とは簡単に言うと証明書が持つメインとなるドメイン名で、-d の一番初めに指定したドメイン名が該当する。
/etc/letsencrypt/ のディレクトリに証明書が格納されている各ディレクトリ名がそれ。
本番環境で作成した証明書を消す場合は、Lets Encrypt サーバーに置いてある履歴を消す必要があるので revoke 処理を行う。
ステージング環境を使用した場合は必ず --staging を付けること。
% sudo certbot-auto revoke --cert-path [fullchain.pem のフルパス]例)
% sudo certbot-auto revoke \
--cert-path /etc/letsencrypt/live/www.example.com/fullchain.pem
revoke しても再作成 (再申請) は可能。消さなくても期限が超えたら消えると思う…。
オーセンティケーターに --manual を選んだとき、ドメイン使用権の認証方式に DNS 認証を使うならば "--preferred-challenges dns" を着ける。
(デフォルトは http)
% sudo certbot-auto certonly --manual --staging \
-m [メールアドレス] -d [ホスト名] \
--manual-public-ip-logging-ok \
--force-renewal --preferred-challenges dns
さて、自ドメインにサブドメイン切って --preferred-challenges dns による自動更新を行ってみる。
参考にしたのは
Certbotによるワイルドカード証明書と自動更新の設定
だが、dns-01 スクリプトの書式に間違いがあったので修正している。
# nsupdate に渡すコマンドの先頭に update の記述が無いので "delete メソッドなんぞ知らぬ！" と怒られる。
まずは Dynamic DNS の準備。
Dynamic DNS のゾーンは分けておかないと元のゾーンが Dynamic DNS によりぐちゃぐちゃにされるのでちゃんと分ける。
以下のように親のゾーンである griffonworks.net. から権限委譲して別ファイルにすると良い。
TSIG 鍵は nsupdate -l で運用する (ローカルホスト限定) ので今のところは不要。
$ORIGIN griffonworks.net. $TTL 86400 @ IN SOA leviathan.griffonworks.net. root.griffonworks.net. ( : (省略) : ddns IN NS sakura.griffonworks.net.[ /var/named/dynamic/ddns_griffonworks_net.zone ]
$ORIGIN ddns.griffonworks.net.
$TTL 60
@ IN SOA leviathan.griffonworks.net. root.griffonworks.net.
( 2018091800 10800 600 604800 60 )
NS ns.griffonworks.net.
named.conf は "_" (アンダーバー/アンダースコア) を使用するので "check-names ignore" は必要。[ /etc/named.conf ]
zone "ddns.griffonworks.net" {
type master;
file "/var/named/dynamic/ddns_griffonworks_net.zone";
allow-update { localhost; };
check-names ignore;
};
この時、/var/named/dynamic/ddns_griffonworks_net.zone のパーミッションは named が更新する必要があるので named:named に chown しておくこと。# mkdir /var/named/dynamic/ # chown named:named /var/named/dynamic/ # chmod 770 /var/named/dynamic/ # vi /var/named/dynamic/ddns_griffonworks_net.zone # chown named:named /var/named/dynamic/ddns_griffonworks_net.zone # chmod 644 /var/named/dynamic/ddns_griffonworks_net.zoneテストするなら以下のように。
ちゃんと
ホスト名 TTL値 IN TXT 値書式でないと受け付けられません。
% nsupdate -l > update add test.ddns.griffonworks.net. 10 IN TXT "teststrings" > send > (CTRL+D で抜ける) % dig TXT test.ddns.griffonworks.net. ;; ANSWER SECTION: test.ddns.griffonworks.net. 10 IN TXT "teststrings" % nsupdate -l %gt; update delete test.ddns.griffonworks.net. %gt; send > (CTRL+D で抜ける) % dig TXT test.ddns.griffonworks.net. (返信無し)
今度は certbot-auto。
まずは前準備としてフック用のスクリプトを用意。
参考：certbot User Guide - Pre and Post Validation Hooks
実行属性は付けておいてください。
オーナーはてきとー。
[ /etc/letsencrypt/renewal-hooks/dns-01-auth.sh ]
#!/bin/sh # certbot-auto を実行すると CERTBOT_VALIDATION に認証キーがセットされる。 [ "$CERTBOT_VALIDATION" = "" ] && exit 0 # nsupdate を localhost モード (-l) で動かす。 cat <<_TXT_ | nsupdate -l update delete _acme-challenge.${CERTBOT_DOMAIN}. IN TXT update add _acme-challenge.${CERTBOT_DOMAIN}. 10 IN TXT "${CERTBOT_VALIDATION}" send _TXT_[ /etc/letsencrypt/renewal-hooks/dns-01-clean.sh ]
#!/bin/sh
cat <<_CMD_ | nsupdate -l
update delete _acme-challenge.${CERTBOT_DOMAIN}. IN TXT
send
_CMD_
まずは初回の証明書発行。ちゃんとステージング環境 (--staging) で試しましょう。
% sudo certbot-auto certonly \
-m [自分のメールアドレス] \
--preferred-challenges dns \
--staging \
--manual \
--manual-public-ip-logging-ok \
-d "*.ddns.griffonworks.net" \
--manual-auth-hook /etc/letsencrypt/renewal-hooks/dns-01-auth.sh \
--manual-cleanup-hook /etc/letsencrypt/renewal-hooks/dns-01-clean.sh
説明。- ドメイン使用権の認証方法に DNS の TXT レコードを使用する (--preferred-challenges dns)
- 認証の承認リクエストを受けた時に実行するスクリプト (--manual-auth-hook)
- 認証の承認リクエストを受けた後に実行するスクリプト (--manual-cleanup-hook)
% sudo certbot-auto 〜 Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator manual, Installer None Obtaining a new certificate Performing the following challenges: dns-01 challenge for ddns.griffonworks.netもしスクリプトにエラーがあったらちゃんとエラーが出る。
Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/ddns.griffonworks.net/privkey.pem Your cert will expire on 2018-12-17. To obtain a new or tweaked version of this certificate in the future, simply run certbot-auto again. To non-interactively renew *all* of your certificates, run "certbot-auto renew"
スクリプトで何をやってるか気になるなら nsupdate -l にパイプしてる内容を一時ファイルに書き出し、一時ファイルを nsupdate に喰わせるスクリプトに変更して、一時ファイルを cat してみると良い。
普段は renew を実行するだけで良い。
% sudo certbot-auto renew --cert-name ddns.griffonworks.net --staging試しに強制的に証明書を更新 (--force-renewal) してみる。
% certbot-auto renew --cert-name ddns.griffonworks.net --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/ddns.griffonworks.net.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for ddns.griffonworks.net
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
% openssl x509 -text -in ./live/ddns.griffonworks.net/cert.pem | more
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Fake LE Intermediate X1
Validity
Not Before: Sep 18 04:26:13 2018 GMT
Not After : Dec 17 04:26:13 2018 GMT
Not Before: が現在の時間になっていることが確認出来る (夏時間に注意)。ちなみに "Issuer: CN=Fake LE Intermediate X1" はステージング環境のこと。
本番だと "Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" になる。
いろいろお試しが終わったら revoke しておきましょう。
% sudo certbot-auto revoke --staging \
--cert-path /etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem
このフック機能、"certbot User Guide - Pre and Post Validation Hooks" を見ると http にも対応しているので、scp とノーパスの鍵を組み合わせれば certbot-auto 実行サーバーと Web サーバーを分離出来たりするが、それはまた別のお話。なお、ネイキッドドメインの DNS 認証については、先に紹介したい「Certbotによるワイルドカード証明書と自動更新の設定」の開設で _acme-challenge ゾーンを個別に切って (権限委譲で分離) Dynamic DNS ゾーンにすることで対応出来た。
% sudo certbot-auto certonly \
-m griffon@griffonworks.net \
--staging --manual --manual-public-ip-logging-ok \
-d "*.griffonworks.net" -d griffonworks.net \
--preferred-challenges dns \
--manual-auth-hook /etc/letsencrypt/renewal-hooks/dns-01-auth.sh \
--manual-cleanup-hook /etc/letsencrypt/renewal-hooks/dns-01-clean.sh
- NO COMMENT -
TrackBack URL:[編]
2018/09/04
台風21号とサーバーメンテナンス
今年最強の台風が来るということで一応警戒はしていたが、予想をはるかに超えた大惨事で外は大変なことになっていた。
# 大阪にしてはこれほど酷いのは珍しい。室戸台風以来？
今日は仕事が休みになったので自宅待機していたが、昼過ぎに暴風が吹いている最中に部屋の電灯がちらちらしはじめる。
と、一瞬ちょっと長めの瞬断が発生。
同時に鯖が電源落ちて死亡。orz
# USP？そんなものはない。
こりゃやばいということで早速シリアルケーブルで繋いで……メインPCにシリアルポートが無い orz
しかたがないのでディスプレイに繋いでコンソールでログオンして確認すると、どうもバッドセクタが出来た模様。
起動するにもかなり面倒なことになっていたが、なんとか復旧したので外付けの USB HDD に dump/restore でシステムドライブのバックアップを取っておく。
# 1年ぶりか？
ついでにそのシステムドライブから USB HDD ブート出来るかも確認してみたが、どうもカーネルはロード出来ているがユーザランド(？)がだめっぽい。
しかし何度かいろいろと変更して試していると、なぜか起動出来るようになったのが更に謎。
システムディスクからは きゅ〜↑〜↓〜〜〜↓↑↑↓↑〜〜〜 というグリスの切れたような抑揚する音がかすかに聞こえたのでこりゃシステムドライブ交換かな、と中を開けて見たら、なんとシステムディスクは PATA でした。orz
# ST3120026A って型番で嫌な予感はしてたんだよね。SATA なら AS だし。
マザー：PATA→SATA：HDD という変換基板はあるものの変換基板が入るスペースがない (直上が HDD ベイ) ので USB ブートで凌ぐか、と思いつつ、とりあえず就寝。
# PCI スロットに SATA 増設 IF 着けることも考えたがブート出来ない。
# 内部 SATA に繋いでる RAID HDD 2本を PCI スロットの SATA に繋げば、と思ったが、atacontrol の RAID が degrade する可能性も有るので出来ればやりたくない。
結局日付変更線が変わって早朝 4時頃までかかって作業が終わったので就寝。
しかしどうも鯖の きゅ〜 という音が気になって仕方がないのでシステムドライブを外すべく一度シャットダウンして HDD の電源とケーブルを抜いて電源 ON ！
きゅ〜〜〜〜
え？HDDじゃない？まさか RAID 側？と思って青くなりつつ RAID の HDD を 1本ずつ抜いてみたが音は収まらず。
ということは電源ファンか？と思って、爪楊枝をつっこみつつ電源を入れてみたが音は消えず。
しばらく音の出所を考えた結果、CPU ファンと予想。
耳を澄ましてみると確かに CPU ファンから聞こえる。
そこで CPU ファンを買い置きしていたバックパネル用の小さめのファンに交換して電源を入れてみたところ、以前より静かになってﾌｲﾀ
ファンは CFY-40S というものでヨドバシに売っていたので、届き次第またメンテナンスします。
ファンの買い置き、マジ重要。
# 大阪にしてはこれほど酷いのは珍しい。室戸台風以来？
今日は仕事が休みになったので自宅待機していたが、昼過ぎに暴風が吹いている最中に部屋の電灯がちらちらしはじめる。
と、一瞬ちょっと長めの瞬断が発生。
同時に鯖が電源落ちて死亡。orz
# USP？そんなものはない。
こりゃやばいということで早速シリアルケーブルで繋いで……メインPCにシリアルポートが無い orz
しかたがないのでディスプレイに繋いでコンソールでログオンして確認すると、どうもバッドセクタが出来た模様。
起動するにもかなり面倒なことになっていたが、なんとか復旧したので外付けの USB HDD に dump/restore でシステムドライブのバックアップを取っておく。
# 1年ぶりか？
% mount /dev/da0s1a /mnt % cd /mnt % dump -0af - / | restore rf -※ちゃんと cd してから restore しましょう。
ついでにそのシステムドライブから USB HDD ブート出来るかも確認してみたが、どうもカーネルはロード出来ているがユーザランド(？)がだめっぽい。
しかし何度かいろいろと変更して試していると、なぜか起動出来るようになったのが更に謎。
システムディスクからは きゅ〜↑〜↓〜〜〜↓↑↑↓↑〜〜〜 というグリスの切れたような抑揚する音がかすかに聞こえたのでこりゃシステムドライブ交換かな、と中を開けて見たら、なんとシステムディスクは PATA でした。orz
# ST3120026A って型番で嫌な予感はしてたんだよね。SATA なら AS だし。
マザー：PATA→SATA：HDD という変換基板はあるものの変換基板が入るスペースがない (直上が HDD ベイ) ので USB ブートで凌ぐか、と思いつつ、とりあえず就寝。
# PCI スロットに SATA 増設 IF 着けることも考えたがブート出来ない。
# 内部 SATA に繋いでる RAID HDD 2本を PCI スロットの SATA に繋げば、と思ったが、atacontrol の RAID が degrade する可能性も有るので出来ればやりたくない。
結局日付変更線が変わって早朝 4時頃までかかって作業が終わったので就寝。
しかしどうも鯖の きゅ〜 という音が気になって仕方がないのでシステムドライブを外すべく一度シャットダウンして HDD の電源とケーブルを抜いて電源 ON ！
え？HDDじゃない？まさか RAID 側？と思って青くなりつつ RAID の HDD を 1本ずつ抜いてみたが音は収まらず。
ということは電源ファンか？と思って、爪楊枝をつっこみつつ電源を入れてみたが音は消えず。
しばらく音の出所を考えた結果、CPU ファンと予想。
耳を澄ましてみると確かに CPU ファンから聞こえる。
そこで CPU ファンを買い置きしていたバックパネル用の小さめのファンに交換して電源を入れてみたところ、以前より静かになってﾌｲﾀ
ファンは CFY-40S というものでヨドバシに売っていたので、届き次第またメンテナンスします。
ファンの買い置き、マジ重要。
- NO COMMENT -
TrackBack URL:[編]
RSS 1.0
1行板
Web日記帳 "さくら" for MySQL
presented by K.O.T.B.GRIFFON (GRIFFON Works)
presented by K.O.T.B.GRIFFON (GRIFFON Works)
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ Ｇ兄
└ 山銀
└ Ｇ兄