タイトルリスト
0 | 1 | 2
 2019/10/09
MBRパーティションとGPTパーティションの混在でgmirrorを作る→その後両方ともGPTパーティションに変更
説明の想定としては、
現在 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

最終:2019/10/09 08:00:17 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
MBRパーティションの内容をGPTパーティションにdump/restoreを使わずにコピーする
MBR パーティションから GPT パーティションに dump | restore を使わずにコピーする方法。
どちらもパーティション単位で 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

最終:2019/10/09 07:09:41 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
GPTパーティションでgmirrorを作ってディスクサイズを広げてみる(GPT)
詳細な説明は端折っているので、おおまかな流れは MBR のそれを参照してください。
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).
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 してから recover しておきましょう。
% 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.
(和訳) gmirror(8) は、ディスクの最後に 1ブロックのメタデータを保存します。GPT パーティションスキームはディスクの最後にメタデータも保存するため、 gmirror(8) で GPT ディスク全体をミラーリングすることはお勧めしません。MBR パーティショニングは、ディスクの先頭にのみパーティションテーブルを格納し、ミラーメタデータと競合しないため、ディスク全体を使用することが出来ます。
つまりは GPT ディスクにパーティション切ってそれをミラーすればいいというわけで。
ここで注意する点は「両方同じパーティションテーブルを持ったパーティションが必要」ということだが、ぶっちゃけ後から追加するディスクが大きければ必ずしも同じパーティションテーブルでなくても良い。

仮にパーティションサイズが元居たパーティションサイズよりも小さい場合はこうなります。
% 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)

最終:2019/10/09 08:07:20 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2019/10/06
gmirrorのディスクサイズを広げてみる(MBR)
ディスク容量の違うディスクを gmirror で使用し、その後大きなドライブを使ったときの対処法をここに残しておく。

想定している内容としては
  • ada2s1d に既にデータが存在する。
  • RAID-1 としてペアにするディスクは ada2 より大きい物を使用する (ada3)。
  • 後日その大きいサイズの HDD に容量を合わせる (ada2 = 5GB / ada3 = 8GB)。
となる。
順序としては
  1. マスターとなるディスク (小さい方) を gmirror label でメンバーに入れる。
  2. 大きいディスクを gmirror insert でメンバーに入れる。(この段階では小さいサイズに合う)
大きいディスクを手に入れたら
  1. 普通に (マルチユーザーモードで) 起動する。
  2. gmirror remove で小さいディスクをメンバーから外す。
  3. gmirror insert で新しいディスクをメンバーに入れる。
  4. 同期が完了するまで待つ。
  5. シングルユーザーモードで起動しなおす。
  6. gmirror resize で metadata を更新する。
  7. gpart resize でスライスとパーティションを広げる。
  8. 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 /mnt
RAID-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*
拡張終わり!!

最終:2019/10/06 05:03:58 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
[修正版] ディスクスペースを拡張してみる@物理ディスク
前回日記で書いた「ディスクスペースを拡張してみる@物理ディスク」だが、一部間違いがあったのでここに書き直す。
ディスクスペースを拡張してみる@物理ディスク

ここでは「スライス自体が本来のディスクサイズよりも小さいもの」を対象に説明している。

つまりはこんな状態。
% 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*

最終:2019/10/06 04:34:55 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2019/10/05
gmirrorの使い方
ぐぐってもイマイチぴんとこなかったのでまとめ。

■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 

最終:2019/10/09 00:56:23 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
gmirroで組んでいたRAIDがクラッシュ
10月4日(金)の夜に特大の雷により瞬停、その影響でサーバーが再起動してしまったが、その後に gmirro の RAID-1 が勝手にリビルドしていた。
ここまではよかったのだが、不幸にもアクティブな 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

最終:2019/10/05 20:56:02 カテゴリ:雑記 
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/30
ディスクスペースを拡張してみる@VMware
VMware はディスクスペースを簡単に拡張できるが、拡張しても実際のディスクスペースは OS 側で拡張しなければならない。
# 拡張しないと「空きスペース」として扱われる。

★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     0
c: には 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 すると容量が増えてる。

念のためちゃんとバックアップは取っておきましょう。


最終:2018/10/01 00:27:44 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/24
Let's Encryptの証明書をapache 2.2にインストールするときのはまりどころ
ふと OpenSSL で証明書の検証がどうなってるかをチェックしてみた。
% 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"
SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/chain.pem"
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/privkey.pem"
と指定して再起動してから openssl を叩いてみたら無事に "Verify return code: 0 (ok)" となった。

ちなみに 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

最終:2018/09/24 02:23:40 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/22
certbot-autoの--pre-hookと--deploy-hookと--post-hook
こいつら微妙に違う。
共通して言えるのは「証明書の更新が必要な時に動く」こと。

--pre-hook更新作業前に1度だけ実行
--deploy-hook証明書ごとに実行
--post-hook更新作業後に1度だけ実行

フローチャート

たとえば証明書が複数有り……
  • 両方更新が無ければ何もせずに終了する。
  • 1枚だけ更新があれば pre → deploy → post の順に実行される。
  • 複数更新があれば pre → 複数回 deploy → post の順に実行される。
ここで重要なのは pre と post は 1回しか実行されないことと deploy は複数回実行されること。

使い分けとしては、証明書をサービスごと (例えば 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}'

最終:2018/09/22 04:00:20 カテゴリ:
タグ:鯖管理
  - 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 の
  • py27-certbot-0.25.1,1
  • py27-certbot-dns-rfc2136-0.25.1
を使用しているので、それらを pkg でインストールしておく。



--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
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
参考:named.log (TXT レコードのクリーンナップ時)
20-Sep-2018 13:25:35.673 update-security: client 219.75.232.51#62492: signer "certbot" approved
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
成功したらあとは certbot renew --cert-name [CN名] で証明書の更新を行う。

ステージングサイトからのドメイン名削除と本番機で反映をお忘れずに。

最終:2018/09/21 19:05:22 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/19
MewとTLS(STARTTLS)とSSL(SMTP over SSL)と
超どはまりした。
6、7時間くらいは失ったんじゃないかな?orz



先に結論を書くと、ちゃんと Mew のマニュアルには書いてあるのだが TLS/SSL という用語がプロトコルの違いだと勘違いしていたのがそもそもの始まりでして。
TLS = STARTTLS
SSL = SMTP over SSL
ということに気がついたのが深夜 3時。
こういうややこしいのは 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
<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
"Creating an SSL/TLS connection..." で刺さる。

今度はちゃんと 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
<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
お、"SMTP LOGIN password (griffon):" でパスワード聞いてきた。

"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 をダウンロードし、鯖の公開出来るようなディレクトリで公開すると良い。
例)
(setq mew-ssl-cert-directory "/usr/local/share/certs")
無い場合は ~/.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)
としてもいいけどフェイクサイトかどうか判断出来ないのであまりよろしくはない。

最終:2018/09/20 01:37:13 カテゴリ:
タグ:鯖管理
  • 安田幸子:他に連絡先が見つかりませんでしたのでコメント欄から失礼いたします。以前イギリスのデジタルマーケティング会社の要請で記事コラボレーションのご依頼についてご連絡させていただきました。この度プロジェクト内容に変更があり、謝礼金も大幅に増額されましたので、貴サイトのように信頼あるサイトで再検討して頂きたくご連絡しております。当方クライアント指定のキーワードを使って、指定ウェブページにリンクする記事執筆或いは既存記事への追記というのがご依頼の内容でございます。こちらのサイトの主旨に背かない範囲でのお願いです。そのようなご依頼に対する対応は可能でしょうか。特定商品の宣伝ではない、一般的な文です。もしよろしければ弊社並びにクライアント情報、新しい謝礼金も含めまして詳細についてメールでご説明させて下さい。どうぞよろしくお願いいたします。sachikoyasuda1604@gmail.com
  • G兄:そのような案件はお受けしておりませんのでよろしくお願いします。
TrackBack URL:[]
 2018/09/17
MewでSSL over POP3/SMTPが使えなくなった
さくらのVPSにメール機能を集約するため、POP3 と SMTP の SSL 化を実施。
代表的なメーラー (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: >
2018.09.17 01:12:07 LOG3[42074:676788736]: SSL_connect: 14094410: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failurer
SSLv3 でアクセスしてる…って、stunnel がリンクしてる OpenSSL のライブラリが古いままだったようなのでビルドし直す。
# ちなみに接続先は 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")
curve = prime256v1
あぁ、chipherが対応してなかったのか〜というわけで問題は Mew。
Mew で stunnel 5系が使えないのでちょっとぐぐってみると、どうやらバージョンアップが必要なようなので Mew 6.8 を落としてきてビルド→インストール。

そして実行してみると無事 SSL over POP3/SMTP が実行できたとさ。

最終:2018/09/20 01:47:35 カテゴリ:
タグ:鯖管理
  - 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 型承認) でいいんじゃね?と思う次第。



まずは基本。
  • -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)
--dry-run を着けない場合は既存の証明書が無効な証明書 (=いわゆる「証明機関で証明されていない無効な証明書」俺俺証明書みたいな感じ) で上書きされるが、その場合は先にバックアップを取っておくか、素直に上書きしてあとから正規の証明書を作り直す。
本番で使ってるなら気をつけてね!!
ここで重要なのは

--staging を着けるとテストモードになる。

なんでテストをするのかって?
ちゃんと証明書の発行が出来るか、更新が出来るかを確認するために。
本番環境では証明書発行・更新の回数制限があるので要注意。
なおテストモードは制限がかなり緩い。
詳しくはこちらを。
制限と仕様からLet's Encrypt(ACMEv1)の話



更新するときは certbot-auto renew を実行。
これだけ。すごいかんたん。
証明書の更新時期が来てなければ certbot-auto が勝手に判断して更新せずに終了。
えらい。

cron に登録しておこう。

なお、1つのサーバー上で複数の証明書を管理している場合は --cert-name で CN の名前を指定すると良い。

例)
% sudo certbot-auto renew --cert-name 2nd.example.com
CN とは簡単に言うと証明書が持つメインとなるドメイン名で、-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

最終:2018/09/18 13:37:20 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/04
台風21号とサーバーメンテナンス
今年最強の台風が来るということで一応警戒はしていたが、予想をはるかに超えた大惨事で外は大変なことになっていた。
# 大阪にしてはこれほど酷いのは珍しい。室戸台風以来?

今日は仕事が休みになったので自宅待機していたが、昼過ぎに暴風が吹いている最中に部屋の電灯がちらちらしはじめる。
と、一瞬ちょっと長めの瞬断が発生。


同時に鯖が電源落ちて死亡。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 というものでヨドバシに売っていたので、届き次第またメンテナンスします。

ファンの買い置き、マジ重要。

最終:2018/09/06 10:02:21 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
0 | 1 | 2
QRコード
携帯サイト試験運用
https://griffonworks.net/nikki/cgi-bin/k.cgi
1行板

備忘録
  • 無し
物欲リスト
  • Canon RF50mm F1.2L USM
  • SIGMA 20mm F1.4 EF Art
  • ニンバス チヌーク
  • OCB-1 ST II
ツーリング ドライブ兼野外撮影予定リスト