Jaybanuan's Blog

どうせまた調べるハメになることをメモしていくブログ

Ubuntuの初期ユーザに関するメモ

Ubuntuのインストール時に作成される初期ユーザに関するメモ。 初期ユーザは、以下のsetup-userというパッケージに含まれるスクリプトで作成される模様。

setup-userインストール後のUbuntuには含まれていないパッケージっぽい。 確認していないが、インストールメディアには含まれていると思われる。

Snapのプロキシサーバの設定

はじめに

フォワードプロキシを利用する環境での、Snapのプロキシサーバの設定方法をメモしておく。

環境

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04.1 LTS"

$ snap --version
snap    2.45.2
snapd   2.45.2
series  16
ubuntu  20.04
kernel  5.4.0-42-generic

設定方法

プロキシサーバを設定するには、以下のコマンドを実行する。

$ sudo snap set system proxy.http=http://[proxserver]:[port]
$ sudo snap set system proxy.https=http://[proxserver]:[port]

また、プロキシサーバの設定ができたかどうかを確認するには、以下のコマンドを実行する。

$ sudo snap get system proxy.http
http://[proxserver]:[port]

$ sudo snap get system proxy.https
http://[proxserver]:[port]

参考

gsettingsを利用してデスクトップの設定一覧を確認する

環境

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04 LTS"

確認方法

以下を実行する。

$ for s in $(gsettings list-schemas); do gsettings list-recursively $s; done

参考

DockerコンテナでSquidを立てる

はじめに

フォワードプロキシのあるテスト環境を簡単に作りたかったので、コンテナイメージsameersbn/squidを利用して、DockerコンテナでSquidを立ててみた。 ただ、設定ファイルsquid.confの編集が必要になり、sameersbn/squidをベースに独自のコンテナイメージを作成することで対処したので、そのメモを残しておく。 方針としては、ホスト側への依存を排除したかったので、設定ファイルsquid.confをホスト側に持たせないようにした。

環境

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04 LTS"

$ docker --version
Docker version 19.03.11, build 42e35e61f3

結論から

コンテナイメージsameersbn/squidに入っているデフォルトのsquid.confは、ローカルホストからしかアクセスを受け付けない状態になっている。 そのため、以下のDockerfileを作成して、編集したsquid.confをコンテナイメージに配置することにした。

FROM sameersbn/squid:3.5.27-2

RUN perl -pi.bak -e 's/#(acl localnet|http_access allow localnet)/$1/' /etc/squid/squid.conf

squid.confの編集内容については、後ほど説明する。 このDockerfileをビルドして、redj/squid:3.5.27-2というタグをつける。 バージョン番号はsameersbn/squidに合わせた。

$ docker build --tag redj/squid:3.5.27-2 build

動作確認のために、docker runする。

$ docker run --name squid --publish 3128:3128 redj/squid:3.5.27-2

以下のようにcurlを実行して、コンテンツが表示されればOK。

$ export https_proxy=http://localhost:3128
$ curl https://www.example.com
(コンテンツが表示される)

コンテナイメージsameersbn/squidの挙動

DockerHubのsameersbn/squidのQuick Startを参考に、以下のようにコンテナを立ち上げたが、

$ docker run --name squid --publish 3128:3128 sameersbn/squid

以下のように、プロキシを利用したcurlの実行がエラーになった。

$ export https_proxy=http://localhost:3128
$ curl https://www.example.com
curl: (56) Received HTTP code 403 from proxy after CONNECT

Squidを経由してHTTPエラー403が出る場合は、Squidの設定ファイルに記載したACL (Access Controll List)に問題があるらしい。

squid.confの見直し

コンテナイメージsameersbn/squidに含まれている、オリジナルのsquid.confを以下に抜粋する。

(前略)

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
#acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
#acl localnet src fc00::/7       # RFC 4193 local private network range
#acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

(中略)

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost

(後略)

上記だと、許可されている(http_access allow)のはlocalhostというデフォルトのACLだけ。 以下のようにローカルネットワークのACLについてのコメントアウトを外すことで、うまく許可することができた。

(前略)

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

(中略)

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

(後略)

ただし、これだと許可し過ぎなので、本来はACLをもう少し絞るべきだと思われる。

ワンライナーでsquid.confのコメントを外す

Dockerfile内でsquid.confのコメントを外すために、ワンライナーを組み立てておく。 sedでもよいが、個人的にはPerlの正規表現ほうが可読性が高く、メンテが楽に感じる。

$ perl -pi.bak -e 's/#(acl localnet|http_access allow localnet)/$1/' /etc/squid/squid.conf

オプションi.bakで、squid.confを上書きしつつバックアップsquid.conf.bakもとっておく。 以下は、ワンライナーの動作確認として、コンテナの中に入ってdiffをとった結果。

# diff /etc/squid/squid.conf.bak /etc/squid/squid.conf
975,979c975,979
< #acl localnet src 10.0.0.0/8   # RFC1918 possible internal network
< #acl localnet src 172.16.0.0/12    # RFC1918 possible internal network
< #acl localnet src 192.168.0.0/16   # RFC1918 possible internal network
< #acl localnet src fc00::/7       # RFC 4193 local private network range
< #acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
---
> acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16    # RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
1190c1190
< #http_access allow localnet
---
> http_access allow localnet

[別案] Dockerfileを利用しない方法

以下のように、コンテナの中の/etc/squid/squid.confを直接編集する同様のことができるが、長い目で見ればコンテナイメージを作成して管理したほうが楽だと思う。

$ docker create --name squid --publish 3128:3128 sameersbn/squid
$ docker cp squid:/etc/squid/squid.conf squid.conf
$ perl -pi.bak -e 's/#(acl localnet|http_access allow localnet)/$1/' squid.conf
$ docker cp squid.conf squid:/etc/squid/squid.conf
$ docker start squid

参考

Nginxでのフォワードプロキシ

www.alibabacloud.com

Nginxは、基本的にはリバースプロキシとして設計されているので、公式的にはフォワードプロキシの機能はないとのこと。 ただ、Alibaba Cloudのエンジニアがフォワードプロキシとして動作するNginxのモジュールを開発して公開している。 記事の内容として、フォワードプロキシの仕組みや成り立ちが分かりやすくまとめられている。

Ubuntu 20.04 LTSで、ユーザにセカンダリグループを追加する場合の注意点

環境

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04 LTS"

現象

dockerをsudoしなくても実行できるようにしたかったので、ユーザredjに対してセカンダリグループdockerを追加した。 しかしながら、ログアウトしてログインし直しても、ユーザredjにセカンダリグループdockerが反映されなかった。

本来は以下のように998(docker)が反映されていてほしかったが、

$ id
uid=1000(redj) (中略),132(sambashare),998(docker)

実際には以下のように反映されていなかった。

$ id
uid=1000(redj) (中略),132(sambashare)

原因

Ubuntu 20.04のディスプレイマネージャであるGDM3について、ユーザのログアウトの後、暫く関連するプロセスを終了しないことが原因らしい。 rootで直接ログインしてプロセスを確認すると、以下のプロセスが暫く残っていた。

# ps -ef | grep -E '^redj' 
redj       22751       1  0 23:31 ?        00:00:00 /lib/systemd/systemd --user
redj       22753   22751  0 23:31 ?        00:00:00 (sd-pam)
redj       24148   22751  4 23:33 ?        00:00:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal
redj       24176   22751  0 23:33 ?        00:00:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

どうもログアウトとログインを素早く行うと、その関連するプロセスが再利用されて(?)、ユーザ情報のリフレッシュがされないらしい。 ログアウト後、20秒ほど(?)待つと関連プロセスが終了するので、その後にログインすると解決する。

参考

Ubuntu 20.04 LTSでKVMの構築を構築する

環境

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04 LTS"

事前準備

CPUがハードウェア仮想化をサポートしているかを検査する。 以下のコマンドを実行した結果、1以上が表示されればOK。

$ egrep -c '(vmx|svm)' /proc/cpuinfo

KVMをインストール

$ sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

virt-managerをインストール

$ sudo apt install virt-manager

参考