
開発用にAWS EC2でMacインスタンスを借りました。
セットアップの際にXCodeのインストールで躓いたので解消方法をメモしておきます。


Amazon EC2 Mac Instanceの利用方法は[こちら](https://qiita.com/hirosys-biz/items/52c971f6076efab3aeb3)の記事を参考にしました。


XCodeをインストールしようとするとこのように十分な空き容量がない旨のメッセージが出てインストールができない。

![xcode](/images/posts/280/289/xcode.png)

Mac App Storeからだと必要以上に容量を求められるらしいので、[developer.apple.com](https://developer.apple.com/download/more/)から直接インストーラーをダウンロードしてみましたが、こちらもダメでした。

![xip](/images/posts/280/289/xip.png)

インスタンスを作成する際に200GBのボリュームを指定しています。
しかし、ディスクの空き容量を確認すると`/dev/disk2s4s1   60Gi`と小さく、割り当てたはずのボリュームが認識していないようです。

```bash
 % df -h
Filesystem       Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk2s4s1   60Gi   14Gi   22Gi    40%  568975  626528225    0%   /
devfs           191Ki  191Ki    0Bi   100%     662          0  100%   /dev
/dev/disk2s6     60Gi   20Ki   22Gi     1%       0  627097200    0%   /System/Volumes/VM
/dev/disk2s2     60Gi  278Mi   22Gi     2%     725  627096475    0%   /System/Volumes/Preboot
/dev/disk2s5     60Gi  244Ki   22Gi     1%      14  627097186    0%   /System/Volumes/Update
/dev/disk2s1     60Gi   23Gi   22Gi    52%  475239  626621961    0%   /System/Volumes/Data
map auto_home     0Bi    0Bi    0Bi   100%       0          0  100%   /System/Volumes/Data/home
/dev/disk3s2    240Mi  240Mi    0Bi   100%     356 4294966923    0%   /Volumes/Google Chrome
```

## Resize the APFS drive to use all available storage

- [Start development of business apps on Amazon EC2 with macOS AMI](https://blogs.sap.com/2021/01/28/start-development-of-business-apps-on-amazon-ec2-with-macos-ami/)

こちらの記事の手順でAPFS(Apple File System)の割り当てを変更して全てのボリュームを利用できるようにしていきます。
Resize the APFS drive to use all available storageの項からの手順です。

以下の４つのステップで進めます。

1. 使っているAPFSコンテナを特定する
2. （オプション）インスタンスのスナップショットを作成する
3. ディスクの修復をする
4. APFSコンテナのリサイズをする

### 1. 使っているAPFSコンテナを特定する

```bash
diskutil list physical external
```
このコマンドでディスクの中でも物理の外付けディスクを確認できる。

```bash
% diskutil list physical external
/dev/disk0 (external, physical):
   #:       TYPE NAME             SIZE     IDENTIFIER
   0: GUID_partition_scheme      *214.7 GB   disk0
   1:        EFI ⁨EFI⁩              209.7 MB   disk0s1
   2: Apple_APFS ⁨Container disk2⁩   64.2 GB   disk0s2 <- これ
```

`disk0s2`がAPFSです。`64.2 GB`しか認識していないことがわかる。

`/dev/disk0`をリサイズします。

### 2. （オプション）インスタンスのスナップショットを作成する

ディスクシステムの設定を変える前にスナップショットやAMIを作成することをお勧めします。

- AMI https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/tkv-create-ami-from-instance.html
- スナップショット https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html#ebs-create-snapshot


![snapshot](/images/posts/280/289/snapshot.png)

### 3. ディスクの修復をする
```bash
% diskutil repairDisk <target disk>

# ex,
% sudo diskutil repairDisk /dev/disk0        
```

リサイズする前に`diskutil repairDisk <target disk>`コマンドを実行してパーティションを修復します。
```bash
% sudo diskutil repairDisk /dev/disk0        
Repairing the partition map might erase disk0s1, proceed? (y/N) y
Started partition map repair on disk0
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Did grow entire partition map
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
The partition map appears to be OK
Finished partition map repair on disk0
```

### 4. APFSコンテナのリサイズをする

すべての準備が整ったので、APFSコンテナのサイズ変更プロセスを開始できます。
このコマンドを入力するだけです。
```
% sudo diskutil apfs resizeContainer disk0s2 0
```

このコマンドで、システムは使用可能なすべてのストレージを使えるようにします。
`0`の代わりに特定の値を設定して利用するサイズを指定できます。


```bash
% sudo diskutil apfs resizeContainer disk0s2 0
Started APFS operation
Aligning grow delta to 150,323,855,360 bytes and targeting a new physical store size of 214,538,608,640 bytes
Determined the maximum size for the targeted physical store of this APFS Container to be 214,537,580,544 bytes
Resizing APFS Container designated by APFS Container Reference disk2
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD - Data was formatted by newfs_apfs (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by diskmanagementd (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by storagekitd (1677.81.1) and last modified by apfs_kext (1677.81.1)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 1 (com.apple.os.update-35C699ADD439C653A3B09EBD8A30FBD366881244EB7C82207A2E135362FCCB7F)
Checking the extent ref tree
Checking the fsroot tree
Checking the file extent tree
Checking volume
Checking the APFS volume superblock
The volume Update was formatted by com.apple.Mobile (1677.81.1) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by com.apple.Mobile (1677.81.1) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Growing APFS Physical Store disk0s2 from 64,214,753,280 to 214,538,608,640 bytes
Modifying partition map
Growing APFS data structures
Finished APFS operation
```

### サイズの確認

サイズが変更できたか確認します。

```bash
% diskutil list physical external
/dev/disk0 (external, physical):
   #:                  TYPE NAME               SIZE       IDENTIFIER
   0: GUID_partition_scheme                   *214.7 GB   disk0
   1:                   EFI ⁨EFI⁩                209.7 MB   disk0s1
   2:            Apple_APFS ⁨Container disk2⁩    214.5 GB   disk0s2
```

APFSコンテナが64.2 GBから214.5GBに変わっていました。

```bash
% df -h
Filesystem       Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk2s4s1  200Gi   14Gi   68Gi    18%  568975 2094534625    0%   /
devfs           195Ki  195Ki    0Bi   100%     674          0  100%   /dev
/dev/disk2s6    200Gi   48Gi   68Gi    42%      48 2095103552    0%   /System/Volumes/VM
/dev/disk2s2    200Gi  278Mi   68Gi     1%     725 2095102875    0%   /System/Volumes/Preboot
/dev/disk2s5    200Gi  244Ki   68Gi     1%      14 2095103586    0%   /System/Volumes/Update
/dev/disk2s1    200Gi   69Gi   68Gi    51% 1766297 2093337303    0%   /System/Volumes/Data
map auto_home     0Bi    0Bi    0Bi   100%       0          0  100%   /System/Volumes/Data/home
/dev/disk3s2    240Mi  240Mi    0Bi   100%     356 4294966923    0%   /Volumes/Google Chrome
/dev/disk0s1    197Mi  5.5Ki  197Mi     1%       0          0  100%   /private/var/tmp/MPOOL4FS
/dev/disk4s1    130Mi  110Mi   21Mi    85%     693 4294966586    0%   /Volumes/Visual Studio for Mac Installer
```
dfコマンドでもSizeが変わっていることが確認できます。
（後日とったのでUsedなど細かい数字は一致しません）

## XCodeのインストール

ストレージが増えたことでMac App StoreからXCodeがインストール出来ました。

以上。

AWS EC2のMacインスタンスで容量が足らずにXCodeがインストールできないときの解決方法


CentOS7のEBSのボリュームを小さくするのがかなり大変だったので、備忘録として残します。
ほぼ[EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)の通り進めています。
自分の知らなかった部分を補足しました。

## EBSは簡単に大きくできるが小さくするのは大変

Elastic Block Store(EBS)はEC2の仮想的な記憶領域で、柔軟に容量を増やしたりスナップショットを取ってバックアップや複製が簡単に出来ます。
ただし、一度大きくしたEBSを小さくすることはできません。
これから新しく作成してAMIに登録する場合は、小さめのボリュームにしておくことをお勧めします。

![ebs](/images/posts/240/243/ebs.png)

では、どうやって小さくするかというと、新しく小さいボリュームのEBSを用意してそこにコピーすることでEBSのボリュームを小さくできます。
EC2のルートデバイスとして認識させる必要があるため、パーティションの設定も正しく行います。

## 標準ファイルシステム ext4とxfs

ボリュームのコピーは標準ファイルシステムによってコマンドが異なるので注意してください。

CentOS7のファイルシステムはxfsで、この記事はそのコピーの方法で進めます。
同じくxfsのOSはAmazon Linux2、Red Hat Enterprise Linux 7など。
対してext4のOSはCentOS6、Amazon Linux、そしてUbuntuです。

ext4のボリューム縮小は[参考1: Amazon EC2ルートボリュームのサイズを縮小してみた](https://techblog.forgevision.com/entry/2018/09/10/172633)を参照されると分かり安いと思います。

xfsはほぼ[参考2: EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)の通り進めました。


## CentOS7のEBSのボリュームを小さくする
AMIで利用しやすいように、200GBのボリュームから20GBへ小さくしました。
OS+ミドルウェアで４GB、swap領域で数GB使っていたので最小を20GBとしています。

参考1に倣って言葉の定義をします。
- 新EBSボリューム：新規起動したEC2インスタンスのEBSルートボリューム
- 旧EBSボリューム：縮小対象EC2インスタンスのEBSルートボリューム


手順は次の通り。
1. 任意の作業用EC2インスタンスに新EBSボリュームと旧EBSボリュームをアタッチする
2. 新EBSボリュームのパーティションを設定する
3. 新旧EBSボリュームをマウントする
4. 新EBSボリュームを旧EBSボリュームと同期する
5. ボリュームを取り外す
6. EC2にアタッチして起動する

### 1. 任意の作業用EC2インスタンスに新EBSボリュームと旧EBSボリュームをアタッチする
EBSをコピーするために新旧EBSボリュームを別の作業用EC2にアタッチします。
作業用EC2はOSがAmazon Linux2です。
インスタンスタイプはt3.microで十分でした。

アタッチ後のブロックデバイス一覧。
```sh
# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk 
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  200G  0 disk <-旧EBSボリューム
└─xvdf1 202:81   0  200G  0 part
xvdg    202:96   0   20G  0 disk <-新EBSボリューム
```
`xvdf`が旧EBSボリュームで`xvdg`が新EBSボリュームです。

### 2. 新EBSボリュームのパーティションを設定する

新EBSボリュームにパーティション`xvdg1`を作ります。
（パーティション内状態でコピーしたら、EC2がルートデバイスとして認識してくれなかった）


```sh
# fdisk /dev/xvdg

fdisk (util-linux 2.30.2) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。

古い xfs 署名は write (書き込み)コマンドを実行すると消えてしまいます。

デバイスには認識可能なパーティション情報が含まれていません。
新しい DOS ディスクラベルを作成しました。識別子は 0x3800409a です。

コマンド (m でヘルプ): n
パーティションタイプ
   p   基本パーティション (0 プライマリ, 0 拡張, 4 空き)
   e   拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (1-4, 既定値 1): 1
最初のセクタ (2048-41943039, 既定値 2048):
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (2048-41943039, 既定値 41943039):

新しいパーティション 1 をタイプ Linux、サイズ 20 GiB で作成しました。

コマンド (m でヘルプ): a
パーティション 1 を選択
パーティション 1 の起動フラグを有効にしました。

コマンド (m でヘルプ): p
ディスク /dev/xvdg: 20 GiB, 21474836480 バイト, 41943040 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3800409a

デバイス   起動 開始位置 最後から   セクタ サイズ Id タイプ
/dev/xvdg1 *        2048 41943039 41940992    20G 83 Linux

コマンド (m でヘルプ): w
パーティション情報が変更されました。
```
設定が日本語になっていた。
`n -> p -> 1 -> a -> w`でディスクサイズと同じ大きさのパーティション`xvdg1`ができる。
`m`でヘルプが見れます。


１度目はパーティション情報の書き込みで失敗している。
下はその時のログ。
再起動してもう一度実行したら成功しました。
```sh
コマンド (m でヘルプ): w
パーティション情報が変更されました。
ioctl() を呼び出してパーティション情報を再読み込みします。
パーティション情報の再読み込みに失敗しました。: Device or resource busy

カーネルは古い情報を使用しています。新しい情報を利用するには、システムを再起動するか、もしくは partprobe(8) または kpartx(8) を実行してください。
```

縮小前後(xvdf/xvdg)で同様の設定になっている事を確認します。
```sh
# fdisk -l
ディスク /dev/xvda: 8 GiB, 8589934592 バイト, 16777216 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 83181C97-6D5E-43C9-9EDE-E2F50EAD5338

デバイス     開始位置 最後から   セクタ サイズ タイプ
/dev/xvda1       4096 16777182 16773087     8G Linux ファイルシステム
/dev/xvda128     2048     4095     2048     1M BIOS 起動

パーティション情報の項目がディスクの順序と一致しません。


ディスク /dev/xvdg: 20 GiB, 21474836480 バイト, 41943040 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3800409a

デバイス   起動 開始位置 最後から   セクタ サイズ Id タイプ
/dev/xvdg1 *        2048 41943039 41940992    20G 83 Linux


ディスク /dev/xvdf: 200 GiB, 214748364800 バイト, 419430400 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x000aec37

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/xvdf1 *        2048 419430366 419428319   200G 83 Linux
```

### 3. 新旧EBSボリュームをマウントする
```sh
# mkdir -p /mnt/old /mnt/new/boot
# mount -t xfs /dev/xvdf1 /mnt/old
# mount -t xfs /dev/xvdg1 /mnt/new

# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk 
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  200G  0 disk
└─xvdf1 202:81   0  200G  0 part /mnt/old <-旧EBSボリューム
xvdg    202:96   0   20G  0 disk 
└─xvdg1 202:97   0   20G  0 part /mnt/new <-新EBSボリューム
```

### 4. 新EBSボリュームを旧EBSボリュームと同期する

この辺りから自分の言葉で表せない、申し訳ないが参考の手順とその時の出力をのせる。

xfs を扱うためのパッケージをインストールしておきます。
- [xfsdump](https://www.atmarkit.co.jp/ait/articles/1804/26/news045.html): XFSファイルシステムをバックアップするために、指定した場所にコピーするコマンド
- [xfsprogs](https://www.atmarkit.co.jp/ait/articles/1804/27/news037.html): xfsdumpのバックアップからファイルを復元するコマンド
インストールコマンド: `yum install xfsprogs xfsdump`

容量により時間が掛かるのでバックグラウンド実行しておきます。
```sh
# cd /mnt/old/
( LANG=C date; nohup xfsdump -J - /mnt/old \
  | xfsrestore -J -p 60 - /mnt/new ; date \
) > /tmp/disk-sync.log 2>&1  < /dev/null &

# ログ
# tail -f /tmp/disk-sync.log
xfsrestore: media label: ""
xfsrestore: file system id: 0f790447-ebef-4ca0-b229-d0aa1985d57f
xfsrestore: session id: 606c299e-31bf-4de9-9bff-36538c642a89
xfsrestore: media id: dafc54f9-af51-4412-88d3-32cfe9298f5d
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsdump: dumping non-directory files
xfsrestore: 21868 directories and 127203 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: status at 10:06:38: 42584/98461 files restored, 47.9% complete, 60 seconds elapsed
xfsdump: ending media file
xfsdump: media file size 4563930720 bytes
xfsdump: dump size (non-dir files) : 4521594712 bytes
xfsdump: dump complete: 111 seconds elapsed
xfsdump: Dump Status: SUCCESS
xfsrestore: restore complete: 112 seconds elapsed
xfsrestore: Restore Status: SUCCESS
2020年  4月  9日 木曜日 10:07:30 UTC


^C[1]+  終了                  ( LANG=C date; nohup xfsdump -J - /mnt/old | xfsrestore -J -p 60 - /mnt/new; date ) > /tmp/disk-sync.log 2>&1 < /dev/null
```

5) grubインストール
chroot
OS起動時に作成されるディレクトリ群をマウントした後、 /mnt/new/ に対して chroot します。 (chroot した事を確認するためにログファイルコピーを行っていますが、必須ではありません。)

```sh
[root@ip-172-31-19-210 old]# cp -ip /tmp/disk-sync.log /mnt/new/var/log/
[root@ip-172-31-19-210 old]# gzip /mnt/new/var/log/disk-sync.log
[root@ip-172-31-19-210 old]# ls -l /mnt/new/var/log/disk-sync.log*
-rw-r--r-- 1 root root 820  4月  9 10:07 /mnt/new/var/log/disk-sync.log.gz
[root@ip-172-31-19-210 old]# mount -t proc /proc /mnt/new/proc
[root@ip-172-31-19-210 old]# mount -t sysfs /sys /mnt/new/sys
[root@ip-172-31-19-210 old]# mount --bind /dev /mnt/new/dev
[root@ip-172-31-19-210 old]# chroot /mnt/new/
[root@ip-172-31-19-210 /]# ls -l /var/log/disk-sync.log.gz
-rw-r--r-- 1 root root 820  4月  9 19:07 /var/log/disk-sync.log.gz
[root@ip-172-31-19-210 /]# 
```

grub xfs

```sh
[root@ip-172-31-19-210 /]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1062.9.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1062.9.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.14.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.14.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.4.2.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-123.8.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-123.8.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f9afeb75a5a382dce8269887a67fbf58
Found initrd image: /boot/initramfs-0-rescue-f9afeb75a5a382dce8269887a67fbf58.img
done
[root@ip-172-31-19-210 /]# grub2-install /dev/xvdg
Installing for i386-pc platform.
Installation finished. No error reported.
```

6) fstab/grub.conf 書き換え
fstab 、grub.conf に UUID 指定がある場合は、書き換えを行います。 (CentOS6 には grub-mkconfig が無いようなので grub.conf は直接書き換えています。)
xfs
UUID指定部分を書き換えます。 CentOS7 では grub2 が導入済みのようなので /etc/grub/ ではなく、 /etc/grub2/ が使用されます。

```sh
[root@ip-172-31-19-210 /]# blkid | grep xvdg
/dev/xvdg1: UUID="80ef9b35-2d25-430c-a753-5f6bbc2955e5" TYPE="xfs"
[root@ip-172-31-19-210 /]#  cp -ip /etc/fstab /etc/fstab.org
[root@ip-172-31-19-210 /]# vi /etc/fstab
# diff /etc/fstab.org /etc/fstab
9c9
< UUID=0f790447-ebef-4ca0-b229-d0aa1985d57f /                       xfs     defaults        1 1
---
> UUID=80ef9b35-2d25-430c-a753-5f6bbc2955e5 /                       xfs     defaults        1 1

# chrootを抜ける
[root@ip-172-31-19-210 /]# exit
exit
```

### 5. ボリュームを取り外す
アンマウント

`proc`、`sys`、`dev`もアンマウントしておく。
```sh
[root@ip-172-31-19-210 old]# cd /
[root@ip-172-31-19-210 /]# umount /mnt/old/
[root@ip-172-31-19-210 /]# umount /mnt/new/proc /mnt/new/sys /mnt/new/dev
[root@ip-172-31-19-210 /]# umount /mnt/new/
[root@ip-172-31-19-210 /]# mount -l | grep "old\|new"
```
ディスク内容の移行が完了したら、 作業用インスタンスから Volume をデタッチして後続作業を行います。

インスタンスを停止して、デタッチ。

## 6. EC2にアタッチして起動する

EC2の `/dev/sda1` にアタッチする。

※ デバイス名が`/dev/sda`だとエラーで`/dev/sdf`だとルートデバイスとして認識しなかった。

```sh
# sshでEC2に接続

$ df -h
df: `/s3': 通信端点が接続されていません
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         472M     0  472M    0% /dev
tmpfs            495M     0  495M    0% /dev/shm
tmpfs            495M   13M  482M    3% /run
tmpfs            495M     0  495M    0% /sys/fs/cgroup
/dev/xvda1        20G  4.5G   16G   23% /
tmpfs             99M     0   99M    0% /run/user/1001
```

いえーあー

AMIに登録して失くさないようにする。

## 参考

- [Amazon EC2ルートボリュームのサイズを縮小してみた](https://techblog.forgevision.com/entry/2018/09/10/172633)
  - コピーの流れが図で分かり易いです。
- [EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)
  - CentOS6(ext4)とCentOS7(xfs)のやり方。この記事がなかったら無理だった。ありがとうございます。
- [今から始めるRHEL 7 第2回 標準ファイルシステムとなったXFS](http://www.intellilink.co.jp/article/column/oss-rh02.html)
  - 問題となったXFSについての解説。
- [Linux で Amazon EBS ボリュームを使用できるようにする | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html)
- [Amazon EBS スナップショット | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSSnapshots.html)


CentOS7（ファイルシステムxfs）のEBSのボリュームを小さくした


アクセス元のIPをログに残したい場合、通常のApacheの設定ではLogFormatに`%h`で出力します。
ただし、ロードバランサーなどプロキシサーバを経由した場合に`%h`に出力されるIPはプロキシサーバのIP（ローカルIP）になってしまいます。

HTTPヘッダーにアクセス元のIと経由したプロキシのIPを保持する規格`X-Forwarded-For`があります。
`X-Forwarded-For`を出力することでアクセス元のIPのログを残す設定を紹介します。

ELBのApplication Load Balancerで話を進めます。

## X-Forwarded-Forを出力するconfの設定

`LogFormat`に`%{X-Forwarded-For}i`を入れます。
`%{Foobar}i`でHTTPヘッダーのFoobarの値を出力します。

```diff
-- LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
++ LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined
```

書式は`X-Forwarded-For: <client>, <proxy1>, <proxy2>`です。

[ELBとApacheの例 | aws.amazon.com](https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-capture-client-ip-addresses/)

## RemoteIPHeader X-Forwarded-Forの場合

`RemoteIPHeader` はApache内部で送信元IPを置き換えるのに使うヘッダーを指定します。

アクセス制御などのため`RemoteIPHeader X-Forwarded-For`を設定すると、`%{X-Forwarded-For}i`の中身が`‐`になりました。
この場合の書式は、`%{X-Forwarded-For}i`ではなくリモートIPアドレス`%a`とする。

例: アクセス制限している場合
```conf
RemoteIPHeader X-Forwarded-For

LogFormat "%a %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined

<Location /admin>
    AllowOverride   All
    Deny from all
    Allow from xxx.xx.xxx.x
    Allow from yyy.yyy.yy.yy/28
</Location>
```
`Allow from`で指定するIPが`X-Forwarded-For`にあるIPになるように`RemoteIPHeader X-Forwarded-For`を設定しています。
LogFormatに`%a`を加えています。

[Apache CustomLogの書式 | httpd.apache.org](https://httpd.apache.org/docs/2.4/ja/mod/mod_log_config.html)に

## IPについて

ちょうど「香川県ネット・ゲーム依存症対策条例」に関しての賛同パブコメのIPがローカルIPだったことが話題になってます。

> 「192.168.7.21」はどのような場合に表示されるのか、香川県議会事務局に聞いたところ、次のような回答がありました。
> 
> 「香川県議会ホームページにご意見・お問い合わせというフォームがあり、そこから送られたものを印刷するとどれもこのような表示になります」（議会事務局）
> 
> 事務局によると、賛成・反対を問わず、県議会ホームページの「ご意見・お問い合わせ」フォームから送信した場合は一律でこの表示になるとのこと。確かに、県のホームページ内から転送されたものであれば、プライベートIPアドレスが記載されていることにも一応の説明はつきます。
> 
> [ゲーム条例パブコメ、同一IPアドレスからの送信が多数？　原本公開で“工作疑惑”広がる → 香川県議会に見解を聞いた | ねとらぼ](https://nlab.itmedia.co.jp/nl/articles/2004/14/news081.html)

個人的に、ゲーム依存症の対策のために条例で時間制限することはやりすぎだと感じます。
この件に関してパブコメの賛同意見に水増しがあったか疑惑が残るが断定できません。
開示されたら続報が出るはず。

ここでの問題は、IPアドレス情報を残しているのに意味がない。
仮にクライアントIPを取れていたら、個人情報には当たらないけど公開するは控えたほうがいいかな。

インフラ屋としてはこういった問題が起きた場合に話題になっても恥ずかしくないインフラ設計・設定を心掛けたい。


LB経由のサーバでクライアントIPをログに残すApacheの設定 X-Forwarded-For


表題の通りAWS RDSのORACLE DBでスナップショットから新しくDBを作るとSIDが元のままだったよって報告です。

### 環境

- AWS RDS
- エンジン: Oracle Standard Edition Two

※ OracleDBに慣れていないので変な表現があるかも。

## 現象

新しくRDSのORACLE DBでスナップショットから別のDBを作りました。
手順は[スナップショットをコピー | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)の通りです。

コピーしたスナップショットを元に「DB インスタンスの復元」を行うと**DB インスタンス識別子**を入力できます。

新しくDBを作成した場合は、DBインスタンス識別子がエンドポイントとSIDに登録されます。
コピーしたスナップショットを元に作成した場合は、SIDが元のインスタンスのままでエンドポイントのみ新しく設定した識別子でした。

DBに接続する際に気をつけてください。

```sql
SQL> SELECT INSTANCE_NAME FROM V$INSTANCE;

INSTANCE_NAME
----------------
前のSID
```

## 参考

- [Oracle SIDを確認・設定する方法](https://sql-oracle.com/?p=1706)


AWS RDSのORACLE DBでスナップショットから新しくDBを作るとSIDが元のままだった


AWSのAmazon RDSのSSL/TSL 証明書の期限が近づき更新するようアナウンスがあり、 2020/03/06 に切れるためその前に対応が必要でした。
更新にはオペレーションが必要なため、備忘録も兼ね手順を残します。

## AWSのアナウンスについて

Classmethodさんの記事が分かり易いので引用させて頂きます。

> - 2020年2月5日: 新CA証明書への強制アップデートについての通知が送付される予定日
> - 2020年2月5日〜3月5日: メンテナンスウィンドウ準拠で新CA証明書へのアップデートが実施される予定。 新CA証明書適用が実施されると短時間のダウンタイムが発生する
> - 2020年3月5日: 現行のCA証明書の利用期限日。現行のCA証明書は利用できなくなり、アップデートがこの日までに実施されていなかった場合は強制アップデートが発生する( ダウンタイム発生 )。新しいCA証明書を持っていないアプリケーションはこの日以降SSL/TLS通信が不可能になる
> 
> [Developers.IO](https://dev.classmethod.jp/cloud/aws/notification-about-certificate-rotation-for-rds-and-aurora/)より

更新には今すぐ更新と次のメンテナンスで更新かを選べます。

詳しくは、[公式](https://aws.amazon.com/jp/blogs/news/amazon-rds-certificate-rotation-2019/)か[Developers.IO](https://dev.classmethod.jp/cloud/aws/notification-about-certificate-rotation-for-rds-and-aurora/)を参照してください。

## SSL/TSL 証明書の期限の確認

データベースの「接続とセキュリティ」タブで証明書の期限を確認できます。
今回の対象は`rds-ca-2015`で以下のように認証機関の項に載っています。

![ssl](/images/posts/220/227/rds-ssl2.png)

## 証明書を更新する

証明書更新が必要なデータベースがある場合、左メニューの「Certificate update」に通知があり、
それをクリックすると更新のメニューが開きます。

![ssl](/images/posts/220/227/rds-ssl.png)

更新したいDBを選択して、即時更新したい場合は「今すぐ更新」を選択。

![ssl](/images/posts/220/227/ssl3.png)

チェックをして「今すぐ適用」をクリックすると証明書が更新されます。

![ssl](/images/posts/220/227/ssl4.png)

更新が完了すると認証機関と証明書の日付が新しくなりました。

## 更新に伴うダウンタイムについて

証明書の更新には再起動がかかるためダウンタイムが生じます。

個人的に３回実行したのでかかった時間をまとめました。

| インスタンス  | DB                          | AZ        | 再起動にかかった時間 |
| ------------- | --------------------------- | --------- | -------------------- |
| db.t3.small   | MySQL 5.6.41                | Single AZ | 11秒                 |
| db.t3.2xlarge | MySQL 5.6.41                | Single AZ | 12秒                 |
| db.t2.small   | Oracle Standard Edition Two | Single AZ | 不明?                |

- フェイルオーバーも特になく `再起動にかかった時間 = ダウンタイム` となっていました。
- 再起動にかかった時間は10秒程でインスタンスクラスの差はほぼなさそう
- アベイラビリティゾーン(AZ)がmultiの場合でも差はないそうです(Developers.IOより)
- 再起動にかかった時間は最近のイベントに`shutdown` `restarted` のログが出るためそこで確認。
  - Oracleはそのログがないため不明としている。（更新してから認証機関を見に行くと既に新しくなっていたため、体感10秒以内に完了している）
- コンソールでの手順はMySQLとOracleで違いはありませんでした。


次の証明書の期限は**2024/08/23** までです。
次回も半年ぐらい前には通知が来ると思うので早めに対応したい。

Amazon RDSのSSL/TSL 証明書を更新する


AWSのCloudFrontが期待した動作をしないときに確認するポイントを症例別にまとめます。
他の方も記事にされているため、この記事はリンク集が主です。
いくつかの私の経験したものは詳しめに書いていきます。

※書きかけなのでまだ２つです。m(__)m

## クエリ文字列が届かない 

確認する設定：**Query String Forwarding and Caching**

デフォルトではクエリ文字列を無視したキャッシュを行う`None (Improves Caching)`が設定されています。
こちらは、リクエストを処理できる可能性を高くしてオリジンの負荷を下げることができますが、**サーバ側にクエリ文字列が届かない原因**となります。

全てのクエリ文字列を渡す場合は`Forward all, cache based on all`とする必要があります。

参考：[クエリ文字列の転送とキャッシュ - 開発者ガイド](https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesQueryString)

## POSTリクエストで403 Forbidden

確認する設定：**Allowed HTTP Methods**

`Allowed HTTP Methods`が`GET, HEAD`になっているとPOST、DELETEなどのメソッドは受け付けません。
`GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`を選びPOST、DELETEなどのメソッドをスルーさせます。

参考
- [Amazon CloudFrontによるPOSTパススルー対応きた！ ｜ DevelopersIO](https://dev.classmethod.jp/cloud/amazon-cloudfront-post-pass-through/)
- [CloudFront Form Submit Error 403 - AWS Developer Forums](https://forums.aws.amazon.com/thread.jspa?threadID=99549)

CloudFrontが期待した動作をしないときに確認する症例集


RDSでないMySQLのユーザー追加方法と同じようにマスターユーザーを追加しようとすると「権限がない」とエラーが出た。
[ドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)によると**マスターユーザーは 1 つだけしか登録できない**。
そこで、マスターユーザーと同等の権限のユーザーを作成する。

手順は[ドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)と同じですので、そちらを参照された方が良いです。

## 環境

- AWS RDS
- MySQL 5.7

設定時にマスターユーザー名を`master_user`としています。

## GRANT ALL PRIVILEGESでマスターユーザーを追加

RDSのMySQLでは`ALL PRIVILEGES`の権限をユーザーに付与させようとするとエラーが出ました。

```sql
mysql> CREATE USER 'master_user2'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.03 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'master_user2'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
ERROR 1045 (28000): Access denied for user 'master_user'@'%' (using password: YES)
```

### マスターと同等のユーザーを追加する

`ALL PRIVILEGES`では追加できませんが、ひとつひとつの権限を全て有効にしてあげればマスターと同等のユーザーにすることができます。

- ユーザー名 : `master_user2`
- パスワード : `password`
- ホスト : `%` ※ワイルドカードです。
のユーザーを追加しようとしています。

```sql
mysql> CREATE USER 'master_user2'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.06 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'master_user2'@'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.06 sec)
```

### 権限の確認

ユーザーの権限の確認方法です。

```sql
mysql> SHOW GRANTS FOR 'master_user2';
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for master_user2@%
                                                                                                                           |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE
VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'master_user2'@'%' WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)
```

### ユーザー削除

```sql
mysql> DROP USER 'master_user2'@'%';
```

### 参考

- [MySQL が実行されている Amazon RDS DB インスタンスの別のマスターユーザーを作成する方法を教えてください。](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)

AWSの公式ドキュメント

- [ユーザーに設定できる権限の種類と一覧 | MySQLの使い方 - DBOnline](https://www.dbonline.jp/mysql/user/index5.html)

権限の種類についてはこちらがわかりやすいです。

RDS MySQLでマスターユーザーを追加する


EC2のインスタンスを停止しても勝手に新しくインスタンスが作られて起動してしまうようになった。
調べていくとよくわからず設定していた**Auto Scaling**が原因だったようです。

## 症状

インスタンスがゾンビのように復活する。
ひとつのインスタンスを停止すると、新たにインスタンスが作成され起動している。
インスタンスのアクションからはそれを解消できるようなメニューは見当たらなかった。

![instance](/images/posts/160/169/instance.png)

勝手に生成されたt2.microの残骸。
(※t2.largeは別途立てたものです。)

## 原因：Auto Scaling

**原因はインスタンスをAuto Scalingのグループにアタッチしていたこと**でした。
下図のように操作を行い自動起動も設定すると同様の現象になります。

![setting](/images/posts/160/169/setting.png)

Auto Scalingはアプリケーションの負荷に応じてインスタンス数を増減できる機能です。
インスタンス数の最小サイズが１としていたため新たに起動していたようです。

参考：[Amazon EC2 Auto Scaling とは](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)

## 解消法

EC2の左メニューにAUTO SCALINGの項があります。
まず、Auto Scalingグループを開いてインスタンスに紐づいているグループを削除します。

![auto](/images/posts/160/169/auto.png)

続いて、同じく左メニューから起動設定を開いて起動設定を削除します。
このとき、Auto Scalingグループが紐づいていると削除できません。

![up](/images/posts/160/169/up.png)

以上でゾンビインスタンスも停止することができました。

## 参考

- [AWSで停止・削除したインスタンスが勝手に再起動されて復活する](https://www.psi-net.co.jp/blog/?p=1132)
- [ELB(v2)配下のEC2を削除するとゾンビ化したインスタンスが残る](https://qiita.com/gimKondo/items/4be92db2adf395a08c97)

このふたつは、ELBを利用していたことによって同様の症状になったようです。
Auto Scalingではなかった場合は、ELBも確認してみて下さい。

EC2のインスタンスを停止しても勝手に新しくインスタンスが起動する


Amazon Linux2にPostgreSQL10を入れたとき`psql`コマンドは使えたが、操作しようとするとき下記のようなエラーが出た。

```sh
psql: FATAL:  role "ec2-user" does not exist

psql: FATAL:  Peer authentication failed for user "postgres"
```

## 環境

- Amazon Linux2
- postgres10

インストールとバージョンの確認は以下。
パッケージマネージャは`yum`ではなく`amazon-linux-extras`を利用した。

```sh
$ sudo amazon-linux-extras install postgres10
$ psql -V
psql (PostgreSQL) 10.4
```

## 現象

ec2-userで操作すると「ロールec2-userは存在しない」とエラーが出た。
`psql -l`はデータベースのリストを確認するコマンド。

```sh
[ec2-user@hostname ~]$ psql -l
psql: FATAL:  role "ec2-user" does not exist
```

そこで、psqlの初期ユーザーの`postgres`で操作を試みた。
「ユーザー”postgres”のピア認証に失敗した」とエラーがでた。

```sh
[ec2-user@hostname ~]$ psql -l -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"
```

また`root`ユーザーで試しても同様。

```sh
[ec2-user@hostname ~]$ sudo psql -l
psql: FATAL:  role "root" does not exist

[ec2-user@hostname ~]$ sudo psql -l -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"
```

## 解決策

psqlの初期ユーザーではなく、実行ユーザーのpostgresで行う。

```sh
[ec2-user@hostname ~]$ sudo -u postgres psql -l
could not change directory to "/home/ec2-user": Permission denied
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(3 rows)
```

psqlの実行権限を変更しないといけない。

### 実行権限を修正

上記のエラーは設定によるものだった。
実行権限は`pg_hba.conf`で設定できる。

```sh
# コピー
$ sudo cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.org

# 確認
$ sudo cat /var/lib/pgsql/data/pg_hba.conf
```

```conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
```

ローカルからの接続のMETHODが`peer`になっていた。
これは実行者のユーザー名とデータベースユーザー名が一致するか検査している。

METHODを`trust`にして接続を無条件で許可するか、`md5`でパスワードを求めるようにか変更すると良い。

設定の詳細はドキュメントにある。

- [PostgreSQL 10.5文書](https://www.postgresql.jp/document/10/html/auth-pg-hba-conf.html)

psql FATA role "ec2-user" does not exist｜Amazon Linux2にPostgreSQL10を入れたとき


Amazon Linux2にPostgreSQL10をインストールして初期設定するまでの手順です。
yumリポジトリにはv10があるので楽に導入できました。

2019-06-26に２回目のインストールを行いました。
この手順で大丈夫そうです。

## 環境

- Amazon Linux2
- postgresql 10.4
- postgresql-server 10.4

## インストールと立ち上げ手順

### info

まずはインストールするパッケージの確認をする。
`yum info`の情報を載せた（一部省略）。

```sh
$ sudo yum info postgresql-server postgresql

Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Installed Packages
Name        : postgresql
Arch        : x86_64
Version     : 10.4
Release     : 5.amzn2.0.2
Size        : 5.2 M
Repo        : installed
From repo   : amzn2extra-postgresql10
Summary     : PostgreSQL client programs


Available Packages
Name        : postgresql-server
Arch        : x86_64
Version     : 10.4
Release     : 5.amzn2.0.2
Size        : 4.9 M
Repo        : amzn2extra-postgresql10/2/x86_64
Summary     : The programs needed to create and run a PostgreSQL server
```

yumリポジトリに[PostgreSQLのRepository Packages](https://yum.postgresql.org/repopackages.php#pg10)を導入が必要かと思ったが、`amzn2extra-postgresql10`に入っているようです。

### install

インストールとバージョンの確認は以下のコマンドでOK。

```sh
$ sudo yum install -y postgresql-server postgresql
```

```sh
$ psql -V
psql (PostgreSQL) 10.4
```

### 起動と自動起動

現時点ではpostgresqlが立ち上がっていないため、操作しようとすると下記のようなエラーが出る。

```sh
$ psql -l
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
```

postgresqlを立ち上げ、自動起動させます。

```sh
# 自動起動
$ sudo systemctl enable postgresql

# 起動
$ sudo systemctl start postgresql

# ステータス確認
$ sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-05-14 14:41:05 JST; 1s ago
  Process: 13572 ExecStartPre=/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS)
 Main PID: 13574 (postmaster)
   CGroup: /system.slice/postgresql.service
           ├─13574 /usr/bin/postmaster -D /var/lib/pgsql/data
           ├─13577 postgres: logger process
           ├─13579 postgres: checkpointer process
           ├─13580 postgres: writer process
           ├─13581 postgres: wal writer process
           ├─13582 postgres: autovacuum launcher process
           ├─13583 postgres: stats collector process
           └─13584 postgres: bgworker: logical replication launcher
```

停止する際は、`sudo systemctl stop postgresql`でOKです。

### 立ち上がらないとき

```sh
$ sudo systemctl start postgresql
Job for postgresql.service failed because the control process exited with error code.
See "systemctl status postgresql.service" and "journalctl -xe" for details.
```

DBの初期化が必要だった

```sh
$ sudo postgresql-setup --initdb
```

## 初期設定

psqlで操作しようとした場合下記のようなエラー出ます。

```sh
$ psql -l
psql: FATAL:  role "ec2-user" does not exist
```

これは`pg_hba.conf`の初期設定が`peer`になっているためです。
一応、実行ユーザーのpostgresで行うと回避できます。

```sh
[ec2-user@hostname ~]$ sudo -u postgres psql -l
```

- [psql FATA role "ec2-user" does not exist｜Amazon Linux2にPostgreSQL10を入れたとき](https://www.suzu6.net/posts/158-amzon-linux2-postgres-error)

### 初期パスワード

ユーザpostgresも初期パスワードの設定が必要です。

```sh
$ sudo passwd postgres
Changing password for user postgres.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
```

### postgresql.conf

`/var/lib/pgsql/data/`に設定ファイルが入っています。
`postgresql.conf`では外部に公開するためIPアドレスを変更しました。

```sh
# オリジナルを残して
$ sudo cp /var/lib/pgsql/data/postgresql.conf /var/lib/pgsql/data/postgresql.conf.org
# 編集する
$ sudo vi /var/lib/pgsql/data/postgresql.conf
```

```diff
-- #listen_addresses = 'localhost'          # what IP address(es) to listen on;
++ listen_addresses = '*'          # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost'; use '*' for all
                                        # (change requires restart)
#port = 5432                            # (change requires restart)
max_connections = 100                   # (change requires restart)
```

### pg_hba.conf

`pg_hba.conf`ではロールを設定します。

```sh
$ sudo cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.org
$ sudo vi /var/lib/pgsql/data/pg_hba.conf
```

ローカルからは認証をなくし、外部からはパスワードが必要になるよう変更します。

```diff
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
-- local   all             all                                     peer
++ local   all             all                                     trust
# IPv4 local connections:
-- host    all             all             127.0.0.1/32            ident
++ host    all             all             0.0.0.0/0               md5
# IPv6 local connections:
-- host    all             all             ::1/128                 ident
++ #host    all             all             ::1/128                 ident
```

認証は以下の方式です。
> - Ident ： DB の所有者がシェルを実行している OS のユーザ名と一致するかで認証
> - MD5 ： PW 認証 (MD5-hashed)
> - Trust ： 認証せず、DB への接続許可 (PW スルー)
> 参考：[PostgreSQL 認証に失敗しないための Ident、MD5、Trust 比較](https://server.etutsplus.com/how-to-configure-postgresql-to-use-ident-md5-trust-authentication/)


設定が済んだら再起動します。

```sh
# 再起動
$ sudo systemctl restart postgresql
```

以上でPostgreSQL10のインストールと初期設定が終わりです。

```sh
# psqlに接続
$ psql -U postgres
```