Linux 使いになりたい人向けの Intel N100 ミニ PC で構築する開発環境（７）- HTTPS 対応版 Gitea

はじめに

これは、Linux 使いになりたい人向けに Intel N100 ミニ PC を使って開発環境を構築する方法を解説する記事の第７弾です。第１弾はLinux 使いになりたい人向けの Intel N100 ミニ PC で構築する開発環境（１） - 構築する開発環境について にあり、そこから第２弾へと続いています。そちらからご覧ください。

ここで使用する Intel N100 ミニ PC の仕様は次のものを前提とします。

項目	内容
OS	Windows 11 Pro
CPU	Intel N100
メモリ	16GB
ストレージ	SSD 512 GB
画面出力端子	HDMI×2
WiFi	5G/2.4G
イーサネット	RJ45×1
Bluetoot	BT4.2
USB	USB3.0×2/USB2.0×2

このマシンで最終的に Windows と Ubuntu Desktop が使えるように環境構築することを目指します。zenn.dev を購読している人のレベルを考えると、画面キャプチャはそれほど必要がないと考えているため少なめです。また、説明についても明示しないとわかりにくいと思われるものに絞っているので少なめです。

なお、実際に作業するときは、ネットワーク回線については数GBのデータをダウンロードしても問題ないものを使うようにしてください。作業の中には、数GBのデータをダウンロードするものも含まれてますので、テザリング環境では使用可能なパケットを使い切ってしまうこともあります。

Gitea については、第５弾と第６弾の説明を読んでから、こちらを読んでいただくことを推奨させていただきます。

HTTPS 対応版 Gitea の設定について

Gitea を Windows マシンで使えるようにしましたが、HTTP で使う設定となっています。HTTP は通信が暗号化されていないため、安全性について心配があります。ここで用意している Gitea はローカルで個人でしか使いませんが、HTTP による Web アクセスに対して警告を出す Web ブラウザもあるため、HTTPS という暗号化された通信を使う設定へ変更したいところです。

ということで、ここでは HTTPS 対応版の Gitea を設定する方法について説明します。Gitea を HTTPS 対応とするためには、次の作業が必要です。

• ホスト名の設定
• 自己署名のサーバー証明書の用意
• Gitea の HTTPS 設定
• Web ブラウザで動作確認

なお、Gitea の HTTPS 対応については、公式ドキュメントの HTTPS setup に説明があります。最新の情報はそちらを参照してください。

Gitea サービス用の URL

最初に Gitea サービスを提供する URL を決めます。URL を決めるにあたっては、完全修飾ドメイン名（FQDN、Fully Qualified Domain Name）を何にするか決める必要があります。

FQDN というのは、インターネット上のコンピュータを一意に識別するために使用するドメイン名の完全な形式のものを指します。インターネットでは、コンピュータの名前をホスト名でつけます。また、コンピュータが属するネットワークにはドメイン名をつけて区別します。FQDN は、＜ホスト名＞.＜ドメイン名＞ という形式の文字列となるので、これを見るとホストが属するネットワーク名もわかります。

説明だとよくわからないかもしれませんが、FQDN の例を見ればわかる人は多いのではないでしょうか。次に FQDN の例を挙げておきます。

• www.example.com
• mail.example.jp
• windev2401eval.local

ここで、example.com や example.jp は例示のために用意されているドメイン名です。また、local は Multicast DNS（mDNS）という仕組みで使われるドメイン名で RFC 6762 に出てきます。

mDNS は LAN 環境でコンピュータのネットワークを自動設定するために使われている仕組みです。そのため、ドメイン名を所有していなくて LAN 環境で FQDN を使いたいときに使用することができます。注意点としては、衝突しやすいコンピュータ名をつけてしまうと外出先で問題が起きやすいということがあります。

たとえば、自宅の LAN 環境で host001 というコンピュータ名のノートパソコンを使っていたとします。外出先で他の人が host001 というコンピュータ名のマシンを使っていたとすると、名前の衝突が起きてしまいます。

そのため、自分でドメインを１つ取得して使えるようにしておくと、そういった心配がなくなります。ただし、ドメインの維持のための費用が必要となるので、このためだけにドメインを取得するのは負担だと思う人も多いことでしょう。

ということで、ここでは衝突しやすいコンピュータ名はつけないという前提で、ドメイン名は local を使って URL のドメイン名を決めることにします。

さて、ここで例としている windev2401eval.local は、コンピュータ名が WINDEV2401EVAL のマシンについて mDNS に対応したネットワークシステム上で特定するために使う FQDN となります。ここで、windev2401eval.local は、コンピュータ名が WINDEV2401EVAL のマシンを識別するために使うのが基本ですが、この文字列自体をドメイン名とみなして扱うこともできます。

そのため、Gitea のサービスを提供する URL のドメイン名としては gitea.windev2401eval.local を使うことが出来ます。

ちなみに、現在使用しているマシンのコンピュータ名を確認するには Git Bash で環境変数 ${COMPUTERNAME} の値を表示します。

User@WinDev2401Eval MINGW64 ~
$ echo ${COMPUTERNAME}
WINDEV2401EVAL

このコマンドの結果は大文字となりますが、FQDN は小文字で指定することが多いです。そのため、このコンピュータを表す FQDN は windev2401eval.local とし、Gitea のサービスを提供する URL のドメイン名は gitea.windev2401eval.local と、全部小文字で表すことにします。

なお、URL のドメイン名の部分については、大文字で指定しても小文字で指定しても、どちらでも良いです。一般的には小文字で表記されていることが多いはずです。

hosts ファイルへの指定

さて、Gitea のサービスを提供する URL のドメイン名を gitea.windev2401eval.local とすることにしました。次は、これをインターネット用のシステムで IP アドレスへ自動変換できるように設定する必要があります。

インターネットでは、コンピュータがネットワーク通信をするときに IP アドレスというものを使って通信先を特定するため、この値が必要です。IP アドレスは 192.168.0.1 といった値となるので、人間にとっては使いづらいものになります。人間が覚えやすいのは win11 や windev といった文字列で、見れば意味がわかるものになります。ドメイン名というのは、IP アドレスよりも人間が覚えやすいので、使われるようになったものなのです。

ここで、インターネット関連の用語として名前解決というものがあります。これは、ドメイン名と IP アドレスの対応を設定しておくことで、ドメイン名から IP アドレスへの自動変換がされる仕組みのことを言います。

名前解決をするためのシステムとしては、DNS（Domain Name System）というものがあります。このシステムを使うことで、ドメイン名と IP アドレスを紐付けることができます。local ドメイン用の mDNS も DNS の一種です。

ここで、本格的に DNS を用意する場合は、クライアント・サーバーシステムのものを使うことになるので、ネームサーバーというものを構築することになるのですが、今回のように１つの FQDN を追加するだけなら hosts ファイルという特別なファイルへ登録すれば済みます。

このファイルは Windows だと /c/Windows/System32/drivers/etc/hosts、Linux では /etc/hosts となります。このファイルへ次の行を追加します。

127.0.0.1    gitea.windev2401eval.local

今回使用しているのは Windows なので、/c/Windows/System32/drivers/etc/hosts へ追加します。Git Bash で「管理者として実行する Git Bash」を起動します。

PowerShell -Command "Start-Process 'C:\Program Files\Git\bin\bash.exe' -Verb RunAs"

次に「管理者として実行する Git Bash」で /c/Windows/System32/drivers/etc/hosts へ 127.0.0.1 gitea.windev2401eval.local のエントリーを追加するコマンドを実行します。

具体的には次のコマンドになります。

HOST_FILE=/c/Windows/System32/drivers/etc/hosts
echo "127.0.0.1  gitea.windev2401eval.local" >> ${HOST_FILE}

ここでは、環境変数 HOST_FILE へ /c/Windows/System32/drivers/etc/hosts を設定してから、echo コマンドと >> を組み合わせています。ここで指定した >> ${HOST_FILE} というのは、環境変数 HOST_FILE に指定したファイルパスへ echo コマンドにより標準出力へ出力されたテキストデータを追加するという処理になります。この処理は >> を指定することにより実行され、この機能のことをリダイレクト機能と言います。

実際に作業をするときは、ファイルの内容を確認しながらになるので、cat コマンドも使いながらとなります。このとき、ファイルパスの指定が楽になるので、環境変数 HOST_FILE を用意して使うようにしています。

User@WinDev2401Eval MINGW64 ~
$ HOST_FILE=/c/Windows/System32/drivers/etc/hosts

User@WinDev2401Eval MINGW64 ~
$ cat ${HOST_FILE}
（略）
127.0.0.1 kubernetes.docker.internal
# End of section

User@WinDev2401Eval MINGW64 ~
echo "127.0.0.1  gitea.windev2401eval.local" >> ${HOST_FILE}

User@WinDev2401Eval MINGW64 ~
$ cat ${HOST_FILE}
（略）
127.0.0.1 kubernetes.docker.internal
# End of section
127.0.0.1  gitea.windev2401eval.local

ここで、Git Bash では /c/Windows/System32/drivers/etc/hosts とは別のファイルとして /etc/hosts ファイルが用意されています。こちらは管理者ではない方の Git Bash で更新します。

HOST_FILE=/etc/hosts
echo "127.0.0.1  gitea.windev2401eval.local" >> ${HOST_FILE}

こちらも実際に実行するときは cat コマンドで確認しながらするのが良いでしょう。そのため、次のような手順で作業することになるはずです。

User@WinDev2401Eval MINGW64 ~
$ cat /etc/hosts
（略）
# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost

User@WinDev2401Eval MINGW64 ~
$ echo "127.0.0.1  gitea.windev2401eval.local" >> /etc/hosts

User@WinDev2401Eval MINGW64 ~
$ cat /etc/hosts
（略）
# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost
127.0.0.1  gitea.windev2401eval.local

基本的な設定は、これでおしまいです。なお、WSL2 の Ubuntu や、Docker コンテナーから Gitea を使う場合は、これとは別に名前解決のための設定が必要になります。それについては、ここでは省略して、必要になったときに設定することにします。

自己署名のサーバー証明書の用意

Gitea を HTTPS 対応とするためには、サーバー証明書というものを用意する必要があります。サーバー証明書を用意するときの一般的な手順は次の通りです。

1. サーバー管理者がサーバー証明書用のファイルを作成
2. サーバー管理者が認証局（CA）へサーバー証明書への署名を申請
3. 認証局（CA）が署名したサーバー証明書をサーバー管理者へ提供
4. サーバー管理者が署名されたサーバー証明書をサーバーへ設置

このように用意されたサーバー証明書は、認証局（CA）によって電子署名がされています。一方、Web ブラウザには CA の証明書が組み込まれています。これらを使って、Web ブラウザはサーバーへ HTTPS でアクセスしたときに自動チェックするようになっています。自動チェックの結果、サーバーが正しいものだと確認ができたら、Web ブラウザはサーバーと暗号化通信を開始します。

ということで、本格的に HTTPS の設定をするなら、CA への申請が必要となります。しかし、個人で LAN 環境で使う場合はそこまでしなくても済むようにしたいところです。その場合は、自己署名のサーバー証明書の用意して使います。

Gitea では自己署名のサーバー証明書を作成するためのコマンド gitea cert があります。このコマンドを実行するときに -host オプションでホストの FQDN を指定します。

gitea cert -host ＜ホストのFQDN＞

また、有効期間を -duration で指定することもできます。次の例では、有効期間を 35040 時間（= 24 時間 × 365 日 × 4 年）として、ホストの指定は gitea.windev2401eval.local としています。

gitea cert -duration=35040h0m0s -host=gitea.windev2401eval.local

このコマンドを実行すると、key.pem と cert.pem ファイルがカレントディレクトリーに作成されます。

実際に作成するときは、/c/gitea/custom/https ディレクトリーを作成して、そこへ key.pem と cert.pem ファイルを置きます。

mkdir /c/gitea/custom/https
cd /c/gitea/custom/https
/c/gitea/gitea.exe cert -duration=35040h0m0s -host=gitea.windev2401eval.local

生成したキーペアの内容を確認するには openssl コマンドを使います。

key.pem は openssl rsa -text を使うと出力結果の modulus に公開鍵の情報、prime1 と prime2 に秘密鍵の情報が表示されます。

openssl rsa -text < key.pem

cert.pem は openssl x509 -text を使うと出力結果にサーバー証明書の情報が表示されます。Validity の Not Before と Not After から有効期間がわかります。また、DNS:gitea.windev2401eval.local に含まれる FQDN から証明書がどのサーバーのものかわかります。

openssl x509 -text < cert.pem

Gitea の HTTPS 設定

サーバー証明書ができたら、Gitea の HTTPS 設定をします。/c/gitea/custom/conf/app.ini を編集して次の３つの項目を追加します。

• PROTOCOL = https
• CERT_FILE = https/cert.pem
• KEY_FILE = https/key.pem

ここで、CERT_FILE と KEY_FILE で指定するファイルパスについては CUSTOM_PATH で指定されているパスとの相対パスを指定する必要があります。この値は「サイト管理」-「設定」の「カスタムファイルのルートパス」で確認することが出来ます。今回の設定対象である Gitea では C:\gitea\custom となっていました。使用するファイルの cert.pem と key.pem は /c/gitea/custom/https に置いてあるので、それぞれ https/cert.pem と https/key.pem となります。

LOCAL_ROOT_URL については、使用するプロトコルが HTTPS となったので、https://localhost:13000/ へ変更します。また、ROOT_URL については、プロトコルだけでなく、ドメイン名を用意した FQDN のものへ変更するので、https://gitea.windev2401eval.local:13000/ とします。

app.ini（抜粋）

（略）
[server]
PROTOCOL = https
CERT_FILE = https/cert.pem
KEY_FILE = https/key.pem
LOCAL_ROOT_URL = https://localhost:13000/
（略）
ROOT_URL = https://gitea.windev2401eval.local:13000/
（略）

設定が終わったら gitea サービスを再起動します。ここでは Git Bash で「管理者として実行する Git Bash」を起動して、sc.exe コマンドで再起動します。Windows のサービスアプリを起動して GUI で再起動をしても良いです。

PowerShell -Command "Start-Process 'C:\Program Files\Git\bin\bash.exe' -Verb RunAs"

sc.exe コマンドでは直接サービスを再起動することはできないので、sc.exe stop で停止、sc.exe query で停止の確認、sc.exe start で起動という手順で再起動することになります。

sc.exe stop gitea
sc.exe query gitea
sc.exe start gitea

実際に実行するときは、出力内容のうち STATE だけわかれば良いのでパイプライン（|）と findstr コマンドを組み合わせて実行します。その場合は、次のような結果となります。

User@WinDev2401Eval MINGW64 /c/gitea/custom/https
$ sc.exe stop gitea | findstr STATE
        STATE              : 4  RUNNING

User@WinDev2401Eval MINGW64 /c/gitea/custom/https
$ sc.exe query gitea | findstr STATE
        STATE              : 1  STOPPED

User@WinDev2401Eval MINGW64 /c/gitea/custom/https
$ sc.exe start gitea | findstr STATE
        STATE              : 2  START_PENDING

User@WinDev2401Eval MINGW64 /c/gitea/custom/https
$ sc.exe query gitea | findstr STATE
        STATE              : 4  RUNNING

結果を見るとわかるように、sc.exe は非同期で実行されるコマンドで、stop や start 時の STATE ではコマンド実行直後の状態が表示されるため、それぞれ STOPPED や RUNNING とはなりません。

ここで gitea サービスの再起動がうまくできない場合は、gitea を sc.exe stop できちんと停止してから、「管理者として実行する Git Bash」で gitea web コマンドを実行します。

/c/gitea/gitea web

このとき、設定が間違っていたら、それに応じたエラーメッセージが表示されます。それを確認したら対応します。設定ファイルを変更したら、gitea web を Ctrl+C で停止してから、再度 gitea web コマンドを実行します。

確認ができたら、gitea web コマンドを終了します。ここで、gitea を停止するには、gitea manager shtudown というコマンドもあるので使ってみましょう。「管理者として実行する Git Bash」を gitea web コマンドを実行するものとは別に起動して gitea manager shtudown を実行します。その後に、sc.exe start コマンドで gitea サービスを起動します。

/c/gitea/gitea manager shtudown
sc.exe start gitea

参考までにPowerShell を使ってサービスを再起動することもできます。管理者で実行する PowerShell を起動したら、Restart-Service でサービスの再起動、Get-Service でサービスの状態を確認します。対象のサービスは -Name オプションで指定します。

PS C:\Windows\System32> Restart-Service -Name gitea
PS C:\Windows\System32> Get-Service -Name gitea

Status   Name               DisplayName
------   ----               -----------
Running  gitea              gitea

他に、Start-Service や Stop-Service といったコマンドもあります。

Web ブラウザで動作確認

HTTPS 対応した Gitea が起動したら、Web ブラウザで https://gitea.windev2401eval.local:13000/ へアクセスして動作確認します。

自己署名のサーバー証明書なので、警告が表示されます。

https://gitea.windev2401eval.local:13000/ アクセス時の画面

ここでは Chrome の場合の画面を表示しています。ここでは「詳細設定」をクリックします。

https://gitea.windev2401eval.local:13000/ アクセス時の画面

自分が用意しているもので安全なので、「gitea.windev2401eval.local に進む（安全ではありません）」をクリックして開きます。

すると、サーバーの信頼ができないという警告が出たままですが、HTTPS による暗号化通信で Web ページが開くようになります。

自己署名のサーバー証明書による HTTPS 対応版の Gitea 画面

ロケーション（URL）を入力する欄の左にある「セキュリティ保護なし」をクリックすると、その情報に関するメニューが表示されます。

「セキュリティ保護なし」の確認

表示されている枠内の「このサイトへの接続は安全ではありません」をクリックすると、これに関する情報を表示するメニューとなります。

証明書の表示

マウスオーバーすると「証明書の表示」が出るアイコンをクリックすると、サーバー証明書が表示されます。

サーバー証明書

SSH 対応

HTTPS 対応をするときにドメイン名を gitea.windev2401eval.local としたので、SSH も合わせましょう。管理者として実行する Git Bash やメモ帳を使って、/c/gitea/custom/conf/app.ini を編集して、SSH_DOMAIN の項目を追加します。

app.ini（抜粋）

[server]
（略）
SSH_DOMAIN = gitea.windev2401eval.local
（略）

HTTPS 対応をしたときと同様にして Gitea を再起動します。

再起動したら、ssh コマンドで gitea.windev2401eval.local へアクセスできることを確認します。

ssh [e-mail]

リモートリポジトリの URL を変更

すでにリモートリポジトリをクローンしてある場合は、その URL について変更する必要があります。git remote コマンドで現在の状態を確認します。

$ cd proj001
$ git remote -v
origin  http://localhost:13000/user001/proj001.git (fetch)
origin  http://localhost:13000/user001/proj001.git (push)

書き換えする場合は、下記のように git remote set-url コマンドを使います。origin について http://localhost:13000 を https://gitea.windev2401eval.local へ置き換えるようにします。

$ git remote set-url origin \
    https://gitea.windev2401eval.local/user001/proj001.git \
    http://localhost:13000/user001/proj001.git

SSH の場合は次のようになります。origin について ssh://User@localhost:2222 を ssh://[e-mail]:2222 へ置き換えるようにします。

$ git remote set-url origin \
    ssh://[e-mail]:2222/user001/proj001.git \
    ssh://User@localhost:2222/user001/proj001.git

以上で、FQDN の HTTPS、SSH に対応した Gitea が使えるようになりました。これで、プライベートな開発環境でも充実した Git を使った開発ができるようになって、開発が捗るようになります。

第８弾へ続く

Gitea からフォークされて開発されている Forgejo という Git リポジトリ管理システムというものがあります。そちらについて、Raspberry Pi OS を使って環境構築をしてみました。Raspberry Pi OS + Raspberry Pi 5 で専用マシンを用意すると、Docker の制約がないので運用がしやすくなり、通常の Linux に関する知識も身につけやすくなります。自宅専用のプライベート Git リポジトリ管理システムとして、手軽に稼働を始めることができるので、Linux 使いになりたい人にはピッタリなはずです。