VMware Fusion(M1 Mac)にUbuntu 22.04.3 LTSをインストール

VMware Fusion にUbuntu Server をインストールする手順の解説です。

VMware Fusion のインストールは「M1 MacにVMware Fusionをインストール」をご参照ください。

環境

  • MacBook Pro / M1 Pro チップ (Apple Silicon)
  • macOS Monterey (12.6.7)
  • VMware Fusion Player (13.5.0)
  • Ubuntu Server (22.04.3 LTS) – Apple Silicon (ARM64)

Ubuntu Serverのダウンロード

Ubuntu のサイトのダウンロードページにアクセスします。

下にスクロールします。
(”Alternative architectures” のクリックでもよいです)

Alternative architecturesUbuntu Server for ARM のリンク”Get Ubuntu Server for ARM” をクリックします。

緑のボタン”Download Ubuntu 22.04.3 LTS” をクリックしてISOファイルをダウンロードします。

ARM64 向けのイメージファイル ubuntu-22.04.3-live-server-arm64.iso がダウンロードされました。

ダウンロードしたファイルに破損などがないか、チェックサムを確認します。

ARM64 向けのチェックサムは、ダウンロードしたファイルの検証方法が記載されたチュートリアル(以下のリンク)から辿ったページにありました。

辿る順番は、3. Download checksums and signatures の本文中のURL(http://releases.ubuntu.com) > Ports, Unsupported, and Experimental Images for Ubuntu > 22.04.3/ > release/ の順で以下のページが表示されます。

下にスクロールすると、チェックサムSHA256SUM のリンクがあります。

SHA256SUMS” をクリックすると複数のチェックサムがプレーンテキストで表示されました。

ARM64 向けイメージファイルのチェックサムは1行目にありました。

5702372d25111e24d59596de62ae24daef873018cbf63c9dd9ff12292a57aca9 *ubuntu-22.04.3-live-server-arm64.iso

このプレーンテキストのページはチェックサムの検証で使える形式になっているので、イメージファイルと同じ場所に保存します。

ターミナルで保存したフォルダにcd してから、下記コマンドを実行して検証します。

% shasum -c SHA256SUMS
ubuntu-22.04.3-live-server-arm64.iso: OK

2行目のようにOK と表示されていれば問題なしです。

Ubuntu Serverのインストール

1. VMware Fusion を起動

VMware Fusion アイコン

Launchpad のVMware Fusion アイコンをダブルクリックします。

2. 新しい仮想マシンの作成

VMware Fusion のウィンドウが表示されました。

左上の[+] をクリックして表示されるメニューの中から[新規…] をクリックします。

ディスクまたはイメージからインストール” の枠内に、ダウンロードしたISO ファイルをドラッグ&ドロップします。

インストールディスクとしてドラッグ&ドロップしたISO ファイルのファイル名が表示され選択されているので、[続ける] をクリックします。

仮想マシンの概要が表示されています。
今回はこの構成のままでよいので[終了] をクリックします。

ここで、仮想マシンをファイルで保存するため、ファイル名の入力を求められます。

任意のファイル名を入力して[保存] をクリックします。

3. 仮想マシンの起動

作成した仮想マシンのウィンドウが既に開いています。

大きい再生ボタンをクリックすると、Ubuntu ServerISO ファイルを使ったインストールが開始します。

ブートローダーが起動しました。

Try or Install Ubuntu Server” を選択してEnter キーを押下します。

  • Enter せずに放置すると、ハイライトされているエントリで処理が開始されます
  • キーボードとマウス操作がゲストOS 側(仮想マシン内)にある状態になるので、ホストOS 側(macOS)に戻したい場合は[control]+[command] を押下します

4. 言語 – select your language

インストーラとインストールするOS のデフォルトの言語を選択します。

English” を選択してEnter キーを押下します。

5. インストーラの更新 – Installer update available

最新版のインストーラーに更新するか選択します。

今回は更新するので、下の[Update to the new installer] を選択してEnter キーを押下します。

6. キーボード – Keyboard configuration

使用している環境に合わせたキーボードを選択します。

今回は”Japanese” を選択します。
Layout で”Japanese” を選択すると、Variant も”Japanese” に変わりました。
下の[Done] を選択してEnter キーを押下します。

7. インストールの種類 – Choose type of install

インストールの種類を選択します。

今回は”Ubuntu Server” を選択して、[Done] でEnter キーを押下します。

  • Ubuntu Server
    • デフォルトの構成。快適に使えるよう厳選されたパッケージが含まれている
  • Ubuntu Server (minimized)
    • 最小の構成

8. ネットワーク – Network connections

ネットワークの設定をします。

VMware 上のDHCP により割り当てられたIPv4 アドレスが表示されています。
今回はこのままの状態で[Done] でEnter キーを押下します。

9. プロキシサーバ – Configure proxy

プロキシサーバの設定をします。

今回はプロキシサーバを設定しないので、このままの状態で[Done] でEnter キーを押下します。

10. ミラーサーバの設定 – Configure Ubuntu archive mirror

Ubuntu のミラーサーバの設定をします。

GeoIP で取得した位置情報を使って選ばれたミラーサーバが自動で入力されています。
今回はこのままの状態で[Done] でEnter キーを押下します。

11. ストレージ – Storage configuration

ストレージの設定をします。

今回は記憶領域全体を使うので、”Use an entire disk” が選択された状態で[Done] でEnter キーを押下します。

  • LVM (論理ボリューム) を設定しない場合は、”Set up this disk as an LVM group” のチェックをOFF にします

ディスクのパーティショニングの設定をします。

パーティションのデフォルトの構成が表示されています。
今回はこのままの状態で[Done] でEnter キーを押下します。

12. インストール実行の確認 – Confirmation destructive action

インストール作業の続行でフォーマットされるのでデータが削除されてもよいのかの確認です。

[Continue] を選択してEnter キーを押下します。

13. プロファイル – Profile setup

sudo が利用できるadministrator 権限のユーザーを作成します。

  • Your name
    • フルネームなど (任意)
  • Your servers name
    • ホスト名 (hostname)
  • Pick a username
    • ログイン時にユーザーの識別子として入力するユーザー名
  • Choose a password / Confirm your password
    • ユーザーのパスワード

任意の値を入力して、[Done] でEnter キーを押下します。

14. アップグレード – Upgrade to Ubuntu Pro

Ubuntu Pro にアップグレードするかの確認です。

今回はアップグレードしないので、”Skip for now” が選択された状態で[Continue] でEnter キーを押下します。

15. SSHサーバ – SSH Setup

OpenSSH サーバの設定をします。

今回はOpenSSH サーバをインストールするので、”Install SSH server” のチェックをON にして、[Done] でEnter キーを押下します。

  • “Import SSH identity” で、プロファイルの設定で作成したユーザーのSSH 公開鍵認証に使う公開鍵をGitHub やLaunchpad から取得して登録することができるようです(今回はやりませんでした)

16. Snapパッケージ – Featured Server Snaps

追加するパッケージを選択します。

今回は追加しないので、何も選択しないで[Done] でEnter キーを押下します。

ここで、Ubuntu Server のインストールが開始されます。
インストールが完了するまで、そのまま待機します。

17. インストール完了 – Install Complete!

“Install complete!” と表示され、下に[Reboot Now] のボタンが表示されたらインストール完了です。

続けて、Ubuntu Server をインストールした仮想マシンを起動します。
[Reboot Now] を選択してEnter キーを押下します。

18. Ubuntu Server 起動・ログイン

Ubuntu Server の仮想マシンが起動します。

“Failed unmounting /cdrom” と表示されました。インストールメディアのマウント解除に失敗したようです。
とりあえずEnter キーを押下します。

“ubuntu login:” と表示されましたが、続けてログが表示されてしまいました。SSH ホスト鍵の情報があるので、初回起動時のみ表示される内容のようです。

この状態でEnter キーを押下します。

末尾に”ubuntu login:” が表示されるので、登録したユーザー名を入力しEnter キーを押下し、続けて”Password:” と表示されたらパスワードを入力してEnter キーを押下します。

Ubuntu のプロンプトの入力ができる状態になりました。ログイン成功です。

正常にインストールできているようです。

インストール直後の状態の確認

ターミナルで確認します。

$ uname -a
Linux ubuntu 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:29:11 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

$ cat /etc/default/locale
LANG=en_US.UTF-8

$ cat /etc/timezone
Etc/UTC

$ cat /etc/default/keyboard
XKBMODEL="pc105"
XKBLAYOUT="jp"
XKBVARIANT=""
XKBOPTIONS=""
BACKSPACE="guess"

$ hostname
ubuntu

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:7b:b2:4c brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.156.134/24 metric 100 brd 192.168.156.255 scope global dynamic ens160
       valid_lft 1636sec preferred_lft 1636sec
    inet6 fe80::20c:29ff:fe7b:b24c/64 scope link
       valid_lft forever preferred_lft forever

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=13.2 ms

$ cat /etc/passwd | grep ubuntu
ubuntu:x:1000:1000:ubuntu:/home/ubuntu:/bin/bash

初期設定

タイムゾーン

UTC から日本のタイムゾーンに変更します。

$ cat /etc/timezone
Etc/UTC

$ timedatectl list-timezones | grep Tokyo
Asia/Tokyo

$ sudo timedatectl set-timezone Asia/Tokyo

$ cat /etc/timezone
Asia/Tokyo

ネットワーク:ホスト名

インストール時に仮で登録していたホスト名を変更します。

$ hostname
ubuntu

$ sudo hostnamectl set-hostname d.test

$ hostname
d.test

ネットワーク:IP アドレス (IPv4)

ホストOS 側の設定ファイルでDHCP で固定アドレスが割り当てられるようにします。

ホストOS 側の作業をする為に、ゲストOS をシャットアウトします。

$ sudo shutdown -h now

ここから、ホストOS 側の作業です。

DHCP サーバの割り当て範囲を確認すると、192.168.156.128 〜 192.168.156.254 でした。

% cat /Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf
 〜 省略 〜
subnet 192.168.156.0 netmask 255.255.255.0 {
	range 192.168.156.128 192.168.156.254;
 〜 省略 〜

ゲストOS に192.168.156.135 が割れ当てられるよう設定します。
MAC アドレスはip a で確認したアドレスを指定します。

% sudo vi /Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf
 〜 省略 〜
####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" #######
 〜 末尾に下記の4行を追記する 〜
host d.test {
    hardware ethernet 00:0c:29:7b:b2:4c;
    fixed-address  192.168.156.135;
}

VMware Fusionのネットワークサービスを再起動します。

% cd /Applications/VMware\ Fusion.app/Contents/Library/

% sudo ./vmnet-cli --stop
Stopped DHCP service on vmnet1
Stopped DHCP service on vmnet8
Stopped NAT service on vmnet8
Stopped all configured services on all networks

% sudo ./vmnet-cli --start
Enabled hostonly virtual adapter on vmnet1
Started DHCP service on vmnet1
Started NAT service on vmnet8
Enabled hostonly virtual adapter on vmnet8
Started DHCP service on vmnet8
Started all configured services on all networks

% sudo ./vmnet-cli --status
DHCP service on vmnet1 is running
Hostonly virtual adapter on vmnet1 is disabled
DHCP service on vmnet8 is running
NAT service on vmnet8 is running
Hostonly virtual adapter on vmnet8 is disabled
Some/All of the configured services are not running

hosts に登録してホストOS からドメイン名で名前解決されるようにします。

% sudo vi /etc/hosts
 〜 末尾に下記の1行を追記する 〜
192.168.156.135 d.test

ここで、ゲストOS を起動します。
設定したIP アドレスが割り当てられているか確認するため、ゲストOS でip a で確認すると、設定したアドレスが割り当てられていました。

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:7b:b2:4c brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.156.135/24 metric 100 brd 192.168.156.255 scope global dynamic ens160
       valid_lft 1030sec preferred_lft 1030sec
    inet6 fe80::20c:29ff:fe7b:b24c/64 scope link
       valid_lft forever preferred_lft forever

SSH

SSH サーバの状態と、ゲストOS のローカル環境でSSH 接続できることを確認します。

$ systemctl is-enabled ssh
enabled

$ systemctl is-active ssh
active

$ ssh ubuntu@localhost

$ exit

ホストOS 側からSSH 接続できることを確認します。

% ssh [email protected]

% exit

ファイアウォール の状態を確認し、SSH 向けポート番号22 をアクセス許可する設定を登録します。
登録したらファイアウォールを有効にします。

$ sudo ufw status verbose
Status: inactive

$ sudo ufw app list
Available applications:
  OpenSSH

$ sudo ufw allow 'OpenSSH'
Rules updated
Rules updated (v6)

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

ホストOS 側からSSH 接続できることを確認します。

ネットワーク:ソケット

接続待ちのソケットの状態を確認します。

$ ss -lnt
State       Recv-Q      Send-Q           Local Address:Port           Peer Address:Port     Process
LISTEN      0           4096             127.0.0.53%lo:53                  0.0.0.0:*
LISTEN      0           128                    0.0.0.0:22                  0.0.0.0:*
LISTEN      0           128                       [::]:22                     [::]:*

$ ss -lnu
State     Recv-Q     Send-Q                  Local Address:Port         Peer Address:Port    Process
UNCONN    0          0                       127.0.0.53%lo:53                0.0.0.0:*
UNCONN    0          0              192.168.156.135%ens160:68                0.0.0.0:*

パッケージの更新

最後にパッケージを最新に更新します。

$ sudo apt update

$ sudo apt upgrade

あとがき

一通りの作業が終わり、やり残した感があることを書いておきます。

  • Ubuntu Server、今度は最小構成でインストールしてみよう
  • SSH サーバの設定で公開鍵をGitHub から登録する手順をやってみたい
  • ファイアウォールを有効にした後、アクセス許可していないポートがきちんとアクセス拒否できているか確認する方法をきちんと整理できていない(telnet d.test 80、nmap -p 80 d.test)

参照

GitLabのメール設定(SendGrid)

前回「UbuntuにGitLabをインストール」の続きです。

GitLab からユーザにメールの通知ができるようにします。
メールの送信はSendGrid というメール配信サービスを利用することにしました。

はじめに

GitLab のメールを送信する方法は下記のどちらかになります。

  • Sendmail やPostfix のようなメールサーバ(MTA)をインストールして送信する
  • SMTP サーバ経由で送信する

今回、前者の方でやろうと進めていましたが手こずったので、諦めて後者の「SMTP サーバ経由で送信する」で対応することにしました。

SMTP サーバの選定

軽く使う程度なので、無料で使えることと設定がしやすさよさそうだったという点で、Twilio社のSendGrid にすることにしました。

SendGrid ロゴ

Free プランは100通/1日を上限として無料で使うことができます。
最初の3ヶ月だけ無料というような期間限定もないです。

SendGrid 料金プラン

環境について

ローカル環境

GitLab はLAN環境でのみアクセス可能(インターネット上に公開しない)

  • Raspberry Pi 4 Model B / 8GB
  • Ubuntu Server 20.04.4 LTS (64bit)
  • GitLab Enterprise Edition 14.9.3-ee (Omnibus)

ウェブサービス

  • SendGrid

SendGrid の設定

1. SendGrid のアカウントを作成

SendGrid のウェブサイトにアクセスして、Free プランでアカウントを作成します。
一般的な手順で作成できたので解説は省略します。

2. Sender Identity の作成

アカウントを作成してログインすると、下記の緑色のバー「最初のメールを送る前にsender identity の作成が必要」があるので、[Create a sender identity] をクリックします。

SendGrid > Sender Identityの作成

※ サイドバーの[Settings] > [Sender Authentication] からもSender Identity を作成することができます。

SendGrid > Sender Identityの作成 > 配信者の認証方法を選択

Sender Identity は下記の2つの方法で作成できます。(両方も可能)

  • Domain Authentication
    • 送信ドメイン認証(SPFとDKIM)。独自ドメインのDNS の設定が必要
  • Single Sender Verification
    • SendGrid を使って送信するメールの差出人の情報を登録する。メールを受信できるメールアドレスが必要

今回は、DNS の設定が不要な”Single Sender Verification” にするので、Single Sender Verification の右の[Get Started] をクリックします。

SendGrid > Sender Identityの作成 > Create a Sender

送信したメールの受信者側に表示される情報(メール差出人の名前・メールアドレス)や迷惑メールの防止に関する法律を遵守する上で必要な情報(会社の住所など)を登録します。

日本の場合は特定電子メール法に、特定電子メールの送信者に課される表示義務(特定電子メールである旨、送信者の情報:氏名・名称・住所、送信者の送信に使ったメールアドレス、送信者の受信用のメールアドレス)というのがあるので、この辺のことと思われます。

今回の使用目的はGitLab ユーザーへのメール通知なので、ここの登録を難しく考えるより、アカウントの乗っ取りを気をつける方を重視しようと思います。(→後述「4. アカウントの保護(2要素認証の設定)」)

入力にあたっては、下記のサイトが参考になりました。

入力して[Create] をクリックすると、”From Email Address” に入力したメールアドレス宛にメールが送られ、下記のページが表示されます。

SendGrid > Sender Identityの作成完了(仮)

届いたメールがこちらです。

SendGrid > Sender Identityの作成 > メール受信で認証

[Verify Single Sender] をクリックします。

SendGrid > Sender Identityの作成 > メール受信で認証完了

SendGrid を使って送信するメールの差出人のメールアドレスが認証されました。
[Return to Single Sender Verification] をクリックすると元のページに戻り、下記のように認証された差出人の情報が表示されています。

SendGrid > Sender Identityの作成完了

3. API Key の作成

サイドバーの[Settings] >[API Keys] をクリックします。

SendGrid > API Keyの作成

[Create API Key] をクリックします。

SendGrid > API Keyの作成 > 権限の選択

API Key Name” に任意の名称を入力して、下記のいずれかを選択します。

  • Full Access
  • Restricted Access
  • Billing Access

今回の使用目的はGitLab ユーザーへのメール通知なので、機能制限ができる”Restricted Access” を選択します。

SendGrid > API Keyの作成 > Restricted Access

Access Details の”Mail Send” の右にある線をクリックして”Full Access” まで青い線が引かれた状態にして[Create & View] をクリックします。

SendGrid > API Keyの作成完了(API Key表示)

作成されたAPI Key が表示されるのでコピーしてどこか安全な場所に保存しておきます。

  • 表示されているAPI Key は再度表示できない
  • 安全な場所に保存とのことなので、パスワードマネージャーに作成したSendGrid のアカウントの一項目の情報として登録しておきました

[Done] をクリックすると元のページに戻り、下記のように作成したAPI Key が表示されます。

SendGrid > API Keyの作成完了

左のAPI Key ID はAPI Key の一部で、中央のAPI KEY はマスクされた状態でクリックなどしても表示されないようになっています。

4. アカウントの保護(2要素認証の設定)

本題からそれますが、前述「2. Sender Identity の作成」の手順の途中で記載したアカウントの乗っ取りを気をつける方を重視の対応です。

サイドバーの[Settings] >[Two-Factor Authentication] をクリックして、Authy またはSMS を選択して2要素認証の設定をします。
※ 手順の解説は省略します

GitLab の設定

1. /etc/gitlab/gitlab.rb

GitLab の公式ドキュメントを参考に設定します。

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.sendgrid.net"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "apikey"
gitlab_rails['smtp_password'] = "the_api_key_you_created"
gitlab_rails['smtp_domain'] = "smtp.sendgrid.net"
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
# If use Single Sender Verification You must configure from. If not fail
# 550 The from address does not match a verified Sender Identity. Mail cannot be sent until this error is resolved.
# Visit https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ to see the Sender Identity requirements
gitlab_rails['gitlab_email_from'] = 'email@sender_owner_api'
gitlab_rails['gitlab_email_reply_to'] = 'email@sender_owner_reply_api'

黄色いマーカーの3ヶ所に任意の値を指定します。

  • smtp_password
    • 作成したAPI Key
  • gitlab_email_from
    • 認証したSender Identity のFrom Email Address
  • gitlab_email_reply_to
    • 認証したSender Identity のReply To

設定ファイルを再読み込みして設定を反映します。

sudo gitlab-ctl reconfigure

2. テストメールの送信

下記のコマンドを実行してテストメールを送信します。

sudo gitlab-rails console

Notify.test_email('[email protected]', 'Message Subject', 'Message Body').deliver_now
→ テストメールが送信される

※ 黄色いマーカーの3ヶ所に送信先メールアドレスメールのタイトルメールの本文を指定します。

3. ユーザの作成

ブラウザでGitLab にroot ユーザなどAdministrator 権限のユーザでログインしてユーザを作成して、作成時に登録したメールアドレスにGitLab からメールが届くか確認します。
届いたメールのリンクをクリックして初期パスワードを設定することで作成したユーザが使えるようになります。
※ 手順の解説は省略します

あとがき

これで普通にGitLab を使えるようになったのではないでしょうか。管理者ユーザと一般ユーザを作って管理するという感じで。

インストール後の推奨される次のステップ、他にも何かあるので必要そうであれば対応してみようと思います。

参考

UbuntuにGitLabをインストール

UbuntuGitLab をインストールします。
筐体はRaspberry Pi で、Ubuntu をインストール直後の状態にインストールします。

環境について

  • Raspberry Pi 4 Model B / 8GB
  • Ubuntu Server 20.04.4 LTS (64bit)

ハードウェア要件

  • ストレージ(空き容量2.5 GB)
  • CPU(推奨4コア、500ユーザー)
  • メモリー(4GB RAM、500ユーザー)

今回使うRaspberry Pi は、CPU は最小要件をぎりぎり満たしていました。

準備

Raspberry Pi はUbuntu をインストールしてパソコンからSSH接続できることを確認していました。
GitLab をインストールする前に下記の作業をしておきます。

1. パッケージを最新に更新

sudo apt update
sudo apt upgrade

2. ストレージの空き領域の確認

pwd
→ /home/ubuntu
df -h ./
→ Filesystem      Size  Used Avail Use% Mounted on
   /dev/mmcblk0p2   30G  2.8G   26G  10% /

インストール

GitLabのコミュニティサイトに推奨のインストール方法として、オールインワンパッケージのインストール手順が記載されていたので、こちらを参考にGitLab のインストール作業を進めます。

オールインワンパッケージ(推奨のインストール方法)

1. 依存パッケージのインストールと設定(必須)

1行目のパッケージのアップデートは準備作業で完了しているので不要。
2行目のライブラリのインストールは、既にSSH接続できているのでOpen SSHサーバは不要ですが、実行しても失敗するだけなのでこのまま実行します。

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates

2. 依存パッケージのインストールと設定(任意)

メールの送信に使うPostfix をインストールします。
外部のSMTPサーバーを使う場合は不要です。

sudo apt-get install -y postfix
→ 設定画面が表示
   "Internet Site" を選択
   "mail name" に外部DNS名 ※今回「a.example」を入力

3. GitLabパッケージのリポジトリへの追加

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

4. GitLabのインストール

EXTERNAL_URL に自分のサーバのURLを指定します。
イントラでHTTPSにしないので、スキーム部はhttpにします。(気が向いたら後でHTTPにします)

sudo EXTERNAL_URL="http://gitlab.a.example" apt-get install gitlab-ee

インストールが完了すると、下記のメッセージが表示されました。

インストール完了

パスワードのリセットを強く推奨と書かれています。

設定のオプションを理解したければ、Omnibus GitLab readme を読めと書かれています。

5. ストレージの空き領域の確認

GitLab をインストール後の容量を確認します。
Used がインストールする前は2.8G だったので、約3.8G 増えています。
ハードウェア要件は空き容量2.5 GB でしたが、1.3G 程余分に使われたようです。
空き容量は22G と潤沢ではないですが、とりあえずはこれでよしとします。

df -h ./
→ Filesystem      Size  Used Avail Use% Mounted on
   /dev/mmcblk0p2   30G  6.6G   22G  24% /

6. rootユーザのパスワードの確認

/etc/gitlab/initial_root_password というファイルにroot ユーザのパスワードが保存されているので確認します。
このファイルは24時間後に自動削除されるようです。

sudo cat /etc/gitlab/initial_root_password
→ Password: <パスワード>

7. ブラウザでGitLab にログイン

インストール完了時に「http://gitlab.a.example」でGitLab が使えるというメッセージがありましたが、LAN環境のサーバでDNSの登録をしていないので、サーバのIPアドレスを指定した下記のURLにアクセスすると、ログインページが表示されました。

  • http://<サーバのIPアドレス>/gitlab/
ログインページ

ドメイン名でアクセスできるようにするために、パソコンのhosts ファイルにサーバの行を追加します。
※ パソコンはMacなので、/etc/hosts を更新します。

sudo vi /etc/hosts
→追加した行
  <サーバのIPアドレス>   gitlab.a.example

下記のURLにアクセスすると、ログインページが表示されました。

  • http://gitlab.a.example
ログインページ

ユーザ名root と先ほど確認したパスワードを入力するとログインに成功しました。

ログイン成功

8. GitLabのバージョンの確認

右上の?アイコンの[Help] をクリックして表示されるページでバージョンを確認すると、14.9.3-ee となっていました。

GitLab Enterprise Edition 14.9.3-ee

OSS版のCE でよかったのですが、公式サイトに推奨は有料版のEEで、ライセンス登録しななくてもCE と同じ機能が使えるとのことだったので、これでよいことにします。

9. rootユーザのパスワード変更

右上のアイコンの[Edit profile] をクリックし、左の縦長のメニューにある南京錠のアイコンをクリックして表示されるページでパスワードを変更します。

インストール直後の状態の確認

1. バンドルインストールされたライブラリの確認

cat /opt/gitlab/version-manifest.txt

大量に表示されたのでここに貼り付けませんが、ぱっと見では下記のページに掲載されている内容と一致していました。

2. 設定ファイルの確認

GitLab の設定ファイル/etc/gitlab/gitlab.rb のコメントアウトされていない行だけを抽出して確認します。(2つ目のgrepで空白行を除去)

sudo grep -v "^#" /etc/gitlab/gitlab.rb | grep -v "^$"
→ external_url 'http://gitlab.a.example'

インストール時に指定したEXTERNAL_URL=”http://gitlab.a.example” がここにセットされていました。
他は全てコメントアウトされていました。

3. サービスの状態を確認

sudo gitlab-ctl status

ちなみに、サービスの起動・停止・再起動は下記のコマンドで実行します。

sudo gitlab-ctl start
sudo gitlab-ctl stop
sudo gitlab-ctl restart

あとがき

ひとまず、インストールして正常に動作していることの確認ができました。最低限の使える状態にはなったようです。
インストール後の推奨される次のステップというのがあるので、まずはこちらを確認して必要なことがあれば対応しようと思います。

参照

OpenSSHサーバでSSH,SCP,SFTP

OpenSSHサーバを使ったSFTP について書きましたが、SSHSCP について何も書いていなかったので一応書いておきます。

環境について

サーバ側の環境

  • Ubuntu

クライアント側の環境

  • macOS Monterey

OpenSSHサーバの環境構築

OpenSSHサーバのインストール

sudo apt install openssh-server

ファイアウォール

SSHの標準ポート22/TCPを開ける

sudo ufw allow ssh

コマンドの実行後の状態を確認する

sudo ufw status verbose
→ 下記の2つが追加されている
  22/tcp (OpenSSH)           ALLOW IN    Anywhere
  22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

/etc/ssh/ssh_config ではなく/etc/ssh/sshd_config

設定した内容(一部抜粋)※既存の設定の変更やコメントアウトなど

AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  /usr/lib/openssh/sftp-server
  • Subsystem sftp はSFTP を使えないようにしたい場合は、コメントアウトする
  • Chroot でSFTPサーバを構築する場合は、Subsystem sftp/usr/lib/openssh/sftp-server ではなくinternal-sftp を指定する→「OpenSSHサーバでSFTP」参照
  • ちなみに、Subsystem sftp/usr/lib/openssh/sftp-server でもChroot なSFTPができてしまいましたが、internal-sftp を指定するのが正しいようです

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認(SSH, SCP, SFTP)

ネットワークを経由しない、サーバ内のローカル接続による接続確認です。

ssh ubuntu@localhost
→ 接続に成功
exit

echo "testdata" > testfile.txt
mkdir temp
scp testfile.txt ubuntu@localhost:temp
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt

sftp ubuntu@localhost
put testfile.txt temp/
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt
quit

接続確認(クライアントからサーバ)

サーバは、前述のローカル接続による接続確認をした後の状態で行います。
なので、/home/ubuntu にtemp ディレクトリが作られていて、中にファイルがない状態です。

接続確認(SSH)

ssh ubuntu@<hostname またはipaddress>
→ 接続に成功
exit

接続確認(SCP)

echo "testdata" > testfile.txt
scp testfile.txt ubuntu@<hostname またはipaddress>:temp

scp ubuntu@<hostname またはipaddress>:temp/testfile.txt ./testfile1.txt
ls testfile1.txt
→ testfile1.txt が格納されている
rm testfile1.txt

接続確認(SFTP)

sftp sftpuser@<hostname またはipaddress>
put testfile.txt temp/
ls temp
→ testfile.txt が格納されている
rm temp/testfile.txt
quit

あとがき

単にOpenSSHサーバを使ってSSH、SCP、SFTP を使える状態にするのは簡単にできました。

ただ、サーバを安全に管理する上では運用面をしっかりする必要がありそうです。
例えば、開発したコンテンツのアップロードだけを行う要員には、Chroot でアクセスできる範囲を制限したSFTPしか使えないユーザを割り当てるなど。

今回ははじめにのようなことを書きたかったので、この辺にしておきます。

OpenSSHサーバでSFTP(公開鍵認証)

直前の投稿「OpenSSHサーバでSFTP」の続きです。
前回はパスワード認証だったので、今回は公開鍵認証でユーザ認証できるようにします。

環境について

※ 前回と同じ、サーバはUbuntu を使っています。

クライアントの環境構築

キーペアの生成

公開鍵認証で使うデジタル署名Ed25519のキーペアを生成

ssh-keygen -t ed25519
→ Your identification has been saved in /Users/xxx/.ssh/id_ed25519
   Your public key has been saved in /Users/xxx/.ssh/id_ed25519.pub
  • 任意のパスフレーズを設定します
  • 生成されるキーペアは、id_ed25519 が秘密鍵、id_ed25519.pub が公開鍵
  • キーペアのファイル名を指定したい場合は、-f オプションを使って指定します(今回は指定しなかったのでデフォルトの”id_ed25519″で作成されました)

公開鍵をサーバにアップロード

前回設定したSFTP(パスワード認証)を使ってアップロードします。
※ 公開鍵 id_ed25519.pub/var/sftp/sftpuser にアップロードします。

sftp sftpuser@<hostname またはipaddress>
→パスワードを入力してユーザ認証

cd sftpuser
put ~/.ssh/id_ed25519.pub
quit

OpenSSHサーバの環境構築

前回作成したユーザ「sftpuser」のユーザ認証の方式をパスワード認証から公開鍵認証に変更します。

公開鍵の設置

SSH接続できるユーザでサーバにSSH接続して、公開鍵を設置します。

su - sftpuser
mkdir ~/.ssh
chmod 700 ~/.ssh
cat /var/sftp/sftpuser/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
exit

sudo rm /var/sftp/sftpuser/id_ed25519.pub

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

設定した内容(一部抜粋)

PubkeyAuthentication yes
AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  internal-sftp

Match User sftpuser
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp
    PasswordAuthentication no
    AuthorizedKeysFile /home/sftpuser/.ssh/authorized_keys
  • PasswordAuthentication no により、パスワード認証ができないようにする
  • AuthorizedKeysFile で公開鍵を指定する

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認(クライアントからサーバ)

SFTP接続の確認(成功)

Mac のターミナルを使ってネットワーク経由でSFTP接続の確認

echo "test" > testfile.txt

sftp -i ~/.ssh/id_ed25519 sftpuser@<hostname またはipaddress>
→パスフレーズを入力して公開鍵認証

cd sftpuser
put testfile.txt
ls
quit

SSHとSCP接続の確認(失敗)

SSHの接続を試してみると失敗します

ssh -i ~/.ssh/id_ed25519 sftpuser@<hostname またはipaddress>
→パスフレーズを入力して公開鍵認証
→ This service allows sftp connections only.

SCPの接続を試してみると失敗します

scp -i ~/.ssh/id_ed25519 testfile.txt sftpuser@<hostname またはipaddress>:
→パスフレーズを入力して公開鍵認証
→ This service allows sftp connections only.

あとがき

パスワード認証の場合、パスワードが漏洩すると第三者がログインできてしまいますが、公開鍵認証はクライアント上に保存した暗号鍵とパスフレーズの両方が第三者の手に渡らなければ第三者によるログインが成功しないので、より安全なユーザ認証の方式といえると思います。

設定がパスワード認証に比べると面倒かもしれませんが、なるべく公開鍵認証を使うようにした方がよいのでしょう。

OpenSSHサーバでSFTP

クライアント上のファイルをサーバにSFTPでアップロードできるようにします。
今回解説する手順は、SFTP専用のユーザを作成して、Chrootにより限定された場所にファイルをアップロードできるようにする手順となります。

環境について

サーバ側の環境

  • Ubuntu
  • OpenSSHサーバ ※インストール済み

クライアント側の環境

  • macOS Monterey

OpenSSHサーバの環境構築

SFTP専用ユーザーの作成

sudo adduser sftpuser

ユーザ認証はパスワード認証を使うので、任意のパスワードを設定します。
※ 公開鍵認証も可能ですが、SFTP中心の解説にしたいので省略します。

SFTP専用グループの作成

sudo groupadd sftponly

ユーザをグループに追加 ※セカンダリグループ

sudo adduser sftpuser sftponly

SFTP専用ディレクトリの作成

SFTP専用ディレクトリの作成 ※Chrootディレクトリ

sudo mkdir /var/sftp
sudo chown root:root /var/sftp

SFTP専用ユーザのディレクトリの作成 ※ここにアップロードする

sudo mkdir /var/sftp/sftpuser
sudo chown sftpuser:sftponly /var/sftp/sftpuser
sudo chmod 755 /var/sftp/sftpuser

OpenSSHサーバの設定

設定ファイルの編集

sudo vi /etc/ssh/sshd_config

/etc/ssh/ssh_config というファイルもあるけれども、設定するのは/etc/ssh/sshd_config

設定した内容(一部抜粋)※既存の設定の変更やコメントアウトなど

AllowTcpForwarding no
X11Forwarding no
Subsystem sftp  internal-sftp

設定した内容 ※末尾に追記

Match User sftpuser
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp
    PasswordAuthentication yes
  • ChrootDirectory は、SFTP接続した際のルートディレクトリを/var/sftp に設定する
  • ForceCommand internal-sftp により、SFTP の利用に限定する(SSHとSCPが使えない)
  • ChrootDirectoryForceCommand internal-sftp の両方を設定することでChroot とSFTP 限定が有効になるようです

設定の有効化

OpenSSH サーバを再起動

sudo systemctl restart sshd

接続確認

サーバのローカル環境上でのSFTP接続の確認

sftp sftpuser@localhost

接続確認(クライアントからサーバ)

SFTP接続の確認(成功)

Mac のターミナルを使ってネットワーク経由でSFTP接続の確認

echo "test" > testfile.txt

sftp sftpuser@<hostname またはipaddress>
→パスワードを入力してユーザ認証

pwd
→ Remote working directory: /
put testfile.txt
→ remote open("/testfile.txt"): Permission denied
cd sftpuser
put testfile.txt
ls
quit
  • 接続した時点のカレントディレクトリは/var/sftp がルートディレクトリとなっていて、ディレクトリの所有者とグループがroot なのでput でファイルをアップロードしようとすると失敗します。
  • cd でカレントディレクトリを/var/sftp/sftpuser に変えてからput するとアップロードが成功します。

SSHとSCP接続の確認(失敗)

SSHの接続を試してみると失敗します

ssh sftpuser@<hostname またはipaddress>
→ This service allows sftp connections only.

SCPの接続を試してみると失敗します

scp testfile.txt sftpuser@<hostname またはipaddress>:
→ This service allows sftp connections only.

あとがき

ChrootDirectory/var/sftp としましたが、ユーザのホームディレクトリ/home/sftpuser を指定してもよさそうです。

SFTPでファイルのアップロード・ダウンロードをするのが専用のユーザなので、SSH接続できるユーザがそのファイルのコピー等をするのにどこが運用上望ましいかで判断する感じでしょうか。