Arch Linuxのインストール(Virtual Box)

# インストールメモと調べもの
これまで１度も使ったことがなかったArch Linuxですが、せっかくなので１度使ってみようかなと思います。
最初なので設定や操作の考え方をメモりながらまとめてみます。

# インストールの考え方
https://wiki.archlinux.jp/index.php/%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%82%AC%E3%82%A4%E3%83%89

UbuntuやRedhatのようにDVDブートすると対話型のインストーラが起動するのではなく、ライブDVDで起動してそこからコマンドを手で叩きながら導入していくという方式なんですね。
結局やることは変わらなくはありますが、選択肢が増える分、いままで適当にOK押していた項目についてもきちんと学ばないといけないわけです。。。

# インストールまでの設定

## 1. VirtualBox用 ssh接続
これから長々コマンドを叩いていくのですが、VirtualBoxの画面に淡々と手打ちをしていくのはめんどくさいです。
手元のコンソールからsshで操作できる状態をまず作ります。
仮想マシンの作成時に2つめのインタフェースでHost-only Adapterをつけておきます。

Install用にライブDVDでの起動が終わったら、以下を叩きます。

```
# ip addr add 10.0.0.32/24 dev enp0s8
# passwd
```

第２インタフェースは通常enp0s8として認識されますので、上記の例ではそちらに10.0.0.32を設定。
sshログインでパスワード無しは通らないので、パスワードを設定。
sshサーバはディフォで起動してくれているので、あとは手元のホストマシンのターミナルからroot@&#xFFF0;10.0.0.32にsshすればOK。

## 2. 時刻同期
最初はこの設定はインストールが一通り終わったあとに他の設定と合わせてまとめてと思ってたのですが、ちゃんと考えると時刻情報はインストールするファイルの作成時刻として残るので、一番最初にやっとかないといけませんね（と、一通りインストールしたあとに思い立ってこの手順を書き足しました。）

```
# timedatectl set-ntp true
```

## 3. ディスクの準備
まずパーティションを切ります。

```
# fdisk /dev/sda
```

今回はsda1をETF、sda2をSwap、sda3をルートディレクトリにします。

以下、fdisk内の操作のメモ。
p: 書き込み予定のパーティションの表示
n: パーティションの作成
t: パーティションタイプの変更。"ef"がブート領域用、"82"はswap用、"83"がディフォルト。
w: パーティションの書き込み

で、フォーマット。

```
# mkfs.fat -F 32 /dev/sda1
# mkfs.ext4 /dev/sda3
# mkswap -f /dev/sda2
```

### 脱線　BIOSとUEFI
今までOSのインストーラに完全に任せていましたが、今回はVirtual Boxで使用している関係でどうも想定と動きが異なる箇所があったので、ちゃんとドキュメント読みました。

https://jp.easeus.com/partition-manager/uefi-bios-differences.html
https://wiki.archlinux.jp/index.php/Arch_%E3%83%96%E3%83%BC%E3%83%88%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9#.E3.83.96.E3.83.BC.E3.83.88.E3.83.AD.E3.83.BC.E3.83.80.E3.83.BC

古くは、マザーボートのBIOSがMBR/PBRを順次読み込んでいく方法。
この場合、ブートディスクの最初のパーティションの頭にブート用のバイナリが書き込まれる、位に認識していました。

一方現在はUEFIを使う方法になっており、MBRではなく、GPT領域にあるEFIブートローダを読み出すと。
こちらは乱暴にディスクの戦闘領域を見るというわけではなく、ファイルシステムを認識して設定ファイルを探して読み込んで進んでいく、、でしょうか。

ということで、マザーボードがどちらの方式化によってディスクのパーティション自体も作り変える必要があります。

ちなみに自身の環境がどちらかを確認する場合の方法は以下。
https://websetnet.net/ja/how-to-check-if-your-computer-uses-uefi-or-bios/
とりあえずこれだけ覚えておけばいいか。

```
# efibootmgr
```

で、今日日の物理PCに導入するときはUEFIでOKなのですが、Virtual Boxに導入するですが、私の環境だとディフォルトだとBIOSを使う設定になってしまってました。
これに気が付かずインストール作業を勧めていて、grub導入あたりでつまづき、これに気がつくに至ったわけでした。。

以下の設定をすれば、UEFIを使うようになりますので、物理に導入するときと同じような条件でインストールできるようになります。
![2021-11-13_16:37:09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/587269/b29355e0-7918-3e65-ec4d-3e5ca5a1a750.png)

今まではインストーラが自動で判定して良しなにディスクを切ってくれてたというわけです。
ディスクパーティションは物理のサーバをガッツリ組むときでもなければ推奨の設定を思考停止して使うようになってしまってたので、ここらへんの知識はBIOS時代で完全に停止してしまってました。
いい勉強になりました。。

## 4. インストール
pacstrapというコマンドを使ってディスクに必要ファイル群を展開して、ある程度展開が終わったらchrootして必要ファイルを展開した領域に入って設定を完成させる、という流れみたいです。

### ディスクのマウント
先にフォーマットした領域を/mntにマウントします。

```
# mount /dev/sda3 /mnt
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot
# swapon /dev/sda2
```

### ベースのインストール
/mnt領域に、ベースになるファイル群を展開します。

```
# pacstrap /mnt base linux linux-firmware vim
# genfstab -U /mnt >> /mnt/etc/fstab
```

vimは後でどうせ使うので、先に入れておきます。
chrootしてから導入してもいいのですけれど。

## 5. ブートローダの設定
ここからchrootした状態の作業に移行します。

```
# arch-chroot /mnt
```

https://wiki.archlinux.jp/index.php/GRUB#.E3.82.A4.E3.83.B3.E3.82.B9.E3.83.88.E3.83.BC.E3.83.AB

```
# pacman -S grub efibootmgr
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub
# grub-mkconfig -o /boot/grub/grub.cfg
```

grubは、grub-installを導入するために必須。
efibootmgrもgrub-installの中で呼び出されるので必須です。
この２つを入れていないと、grub-installが通りません。

grub-installコマンドで、/boot/EFIと/boot/grubが出来上がります。
bootloader-idの意味はよく理解できてませんが、マウントし直しても起動できるという記載をみて"boot"としたら起動ができず、名称を上記の"grub"に変えたという経緯がありました。勉強が足りてないところです。
また、公式のDOC上は--boot-directoryというオプションがあり、そちらのほうが効率的（？）な構成になるように見えるのだが、このオプションの有無で/bootに展開されるファイルのパスが変わる感じはなし。
総じてちゃんと調べきれてません。

これもディストリにまかせっきりにしてたところですね。。

### マイクロコードの配置
もう１点、「マイクロコード」とやらの導入が必要になるようです。
CPUがIntelかAMDかで変わる、と。
確認方法は以下。

```
# cat /proc/cpuinfo
```

VirtualBoxはオプションをあえて有効にしていない限りはホストマシンと同一になるのですね。
インテルの場合は以下。

```
# pacman -S intel-ucode
# grub-mkconfig -o /boot/grub/grub.cfg
```

これなくても動くのかな、、と思いもしつつ、試してません。

## 6.ネットワーク周り
これを済ませておかないと、再起動後に導入漏れのパッケージがあった場合に追加導入できず、どうにもならなくなります。
Ubuntu18系やRHELのNetworkManagerやUbuntu 20系のnetplan等、ディストリごとの差分が大きい領域だと思ってます。
Arch Linuxは軽くググるとnetctlを使っているようですが、ライブDVDにはnetctlが入っておらず、代わりにnetplanが入ってるぽいのですが、、

Archlinuxの公式サイトではnetctlで手順が公開されてます。
https://wiki.archlinux.jp/index.php/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E8%A8%AD%E5%AE%9A

でも、systemd-networkdを使う方法なら、追加パッケージ一切無しで大丈夫なようです。
今回はsystemd-networkdを使う設定でいきます。

```
# cat /etc/systemd/network/enp0s3.network
[Match]
Name=enp0s3

[Network]
DHCP=ipv4

# cat /etc/systemd/network/enp0s8.network
[Match]
Name=enp0s8

[Network]
Address=10.0.0.32/24

# systemctl enable systemd-networkd
```

リゾルバも、DHCPからとって来てくれたりしないので手打ちで。
。。。RHEL5の時代に戻ったかのような錯覚を覚えます。

```
# cat /etc/resolv.conf
nameserver 8.8.8.8
```
↑修正。これchroot時は扱いが違うみたいで、ここで書き換えても再起動後にクリアされてしまう。
なので、ここでやっても意味がないっぽい。

あとsshサーバも仕込みます。

```
# pacman -S openssh
# systemctl enable sshd
```

公開鍵以外の禁止などなどは流石に後回しで。

## 7.その他設定
もうそろそろお腹いっぱい気味ですが、もう一息。

再起動してからの実施でもOKな気はしますが、一度起動するとログが残りますので、それに関係しそうな設定はchroot状態で忘れずに実施しておきます。

### ホスト名

```
# echo "<hostname> > /etc/hostname
```

### タイムゾーン
あとでも全然いいのですが、一応。

```
# tzselect
4) Asia
20) Japan
1) yes
```

### シスログ
rsyslogとsyslog-ngと推奨どっちかな、、と思って軽くググりませんでしたが、なんとなくsyslog-ngが多いかな、という感じで、明確な情報なかったです。
なので、syslog-ngで行くことにします。

```
# pacman -S syslog-ng
# systemctl enable syslog-ng＠default.service
```

上記でシンプルにsyslog-ngを指定するのではなく"@&#xFFF0;default"がついている理由ですが、これは並行で複数起動されることが想定されるサービスはsyslog-ng@&#xFFF0;.serviceと言うような名称で/lib/systemd/systemに配置されていて、systemctlで有効化するときに@のあとに一位識別子にできる文字列をくっつけて起動したり登録したりする、というものなんだそうです。
これはArchLinuxに限った話ではないのですが、Ubuntuだとインストール時にサービス登録も一緒にやってくれるので、全然意識してませんでした。

### アカウント周り

```
# passwd
# pacman -S sudo
# vim /etc/sudoers
%wheel ALL=(ALL) ALLのコメントアウトを解除
# useradd -m -G <new group>,wheel <new account>
```

とりあえずこんなところでしょうか。

# まとめ
こんなところで一通りスタンドアロンで動かしていい状態になるかと思います。
あとは再起動して、改めて新しく作った環境の中で細かい設定入れてディスプレイマネージャ入れて、、となっていくのですが、、
今日はもう限界。

改めてLinuxの勉強をするという意味では非常に良い機会になったのですが、今までディストリに任せていたものをすべて自分で選び直して行く必要があるので、その分の負荷がでかいでかい。
また、SELinuxやAppArmorのようなセキュアOSの機能を固めようと思ったらどうなるのか、、などと考え始めると果てしなく気が遠くなります。
きちんと動くでしょうし、ドキュメントもしっかり揃っているのでしょうけれど。

ただし、逆に興味深い点も多々あります。
ローリングリリースの恩恵で新しいアプリケーションが安定して動くか、逆に専用パッケージを用意してもらえないから扱いにくいだけか（Splunkとか）。
脆弱性が出たときの修正パッケージのリリース速度はどのくらいか。

また時間をとって、ある程度は使ってみたいと思います。

少なくともセキュリティ周りは商用ソフトが対応してないでしょうから仕事で使うことはないですし、そうなると自分でサーバ用途で使うことは無いとは思いますけれど。

今日はここまで。