インフラTips on えやみぐさ

Ubuntu, ファイルシステムがマウントされていない場合に書き込みを失敗させる

Sat, 09 Dec 2023 17:25:00 +0900

Ubuntu 22.04
ext4ファイルシステム

外部ストレージなどのファイルシステムのマウントに失敗したとき、定期実行スクリプトやDockerコンテナなどが、実際にはマウントされていないマウントポイント以下に書き込みしてしまう場合があります。

/etc/fstabからnofailの指定を外せば、マウントに失敗した場合にOSが起動しなくなることで誤った操作を防げますが、外部ストレージと関係のない他のサービスが共存している、遠隔操作を前提とした運用をしている、などの理由で、OSは起動してほしい場合があります。

マウントポイントがext4ファイルシステムにある場合、chattrコマンドを使って、変更を禁止することができます。

/mnt/mystorageのマウントを解除した状態で、以下のように指定します。

chattr +i /mnt/mystorage

これによりマウントしている間、immutable属性がなくなり、変更できるようになります。

mount /mnt/mystorage

MinIO CLI（mcコマンド）でエイリアスが登録されているか確認する

Sat, 09 Dec 2023 17:05:00 +0900

$ mc --version
mc version RELEASE.2023-12-02T11-24-10Z (commit-id=d920e2b34b22a15bca4cd081201d3b301c623d87)
Runtime: go1.21.5 linux/amd64
Copyright (c) 2015-2023 MinIO, Inc.
License GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>

MinIO CLI（mcコマンド）では、サーバーURLや認証情報などをmc alias setコマンドで保存して、設定したエイリアスを使って操作します。

mc cpやmc mirrorでは、{alias}/{bucket}/{object}のように操作対象のオブジェクトを指定します。このときaliasが登録されていなかった場合、ファイルシステム上の相対パスとして扱われるため、意図しない操作が行われるおそれがあります。

エイリアスmyaliasが登録されているかどうかは、mc alias list {alias}コマンドの終了コードで判別できます。終了コードが0の場合、エイリアスは存在します。終了コードが1の場合、エイリアスは存在しません。

mc alias list myalias

echo $?

シェルスクリプトでは、以下のようなコードを追加して、エイリアスが存在しなかった場合にスクリプトを異常終了させられます。

# set +e

# check alias exists
mc alias list myalias >/dev/null 2>/dev/null
if [ $? != 0 ]; then
    echo "Error: mc alias myalias does not exist" > /dev/stderr
    exit 1
fi

# set -e

Dockerコンテナ内の名前解決をプライベートIPアドレスにする

Sat, 09 Dec 2023 16:50:00 +0900

Docker Engine 24.0
Docker Compose 2.21

プライベートDNSを運用しているネットワークで、 Dockerコンテナからネットワーク内の別のホストに通信したいとき、デフォルトではGoogle Public DNS8.8.8.8でホスト名がグローバルIPアドレスに解決されるため、 ISPやCloudflare Tunnelなどの外部を経由して通信することになり、非効率で危険な通信経路になります。

また、IPアドレスによるアクセス制限を設けている場合、プライベートIPアドレスがソースとなる通信になるように通信経路を制御したい場合があります。

以下の設定により、コンテナ内でexample.comが192.168.0.50に解決されるようになります。

Docker

sudo docker run --rm --add-host "example.com:192.168.0.50" hello-world

Managing /etc/hosts - Docker run reference | Docker Docs

Docker Compose

services:
  app:
    image: hello-world
    extra_hosts:
      - "example.com:192.168.0.50"

extra_hosts - Services top-level element | Docker Docs

Docker Registryをホストしてhtpasswdで認証する

Sat, 09 Dec 2023 14:50:00 +0900

htpasswdファイルの作成

htpasswdファイルを作成します。 registryイメージ（Distribution Registry）はbcrypt形式のパスワードのみサポートしているため、パスワードをbcrypt形式でハッシュ化する必要があります。

sudo apt install apache2-utils

mkdir auth
cd auth

htpasswd -cB htpasswd myuser

永続化ディレクトリの作成

mkdir data

docker-compose.ymlファイルの作成

services:
  registry:
    image: registry:2
    restart: always
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
    # ports:
    #   - "0.0.0.0:5000:5000"
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth

コンテナの実行

sudo docker compose up -d

コンテナのTCP 5000番ポートでDocker Registry HTTP APIがリッスンします。このポート宛にCloudflaredやリバースプロキシを設定して、https://docker.example.comのようにサービスを公開します。

Dockerコンテナのメモリ使用量を制限する

Sat, 09 Dec 2023 14:10:00 +0900

Docker Engine 24.0
Docker Compose 2.21

Docker

# 100 MB
sudo docker update --memory "100m" "$CONTAINER_ID"

# 1 GB
sudo docker update --memory "1g" "$CONTAINER_ID"

# 制限を解除
sudo docker update --memory "0" "$CONTAINER_ID"

Docker Compose

app:
  image: hello-world
  deploy:
    resources:
      limits:
        memory: '1g'

参考

DockerコンテナのCPU使用量を制限する

Sat, 09 Dec 2023 14:00:00 +0900

Docker Engine 24.0
Docker Compose 2.21

Docker

# CPU 1個
sudo docker update --cpus "1" "$CONTAINER_ID"

# CPU 0.01個（最小）
sudo docker update --cpus "0.01" "$CONTAINER_ID"

# 制限を解除
sudo docker update --cpus "0" "$CONTAINER_ID"

Docker Compose

app:
  image: hello-world
  deploy:
    resources:
      limits:
        cpus: '0.1'

参考

Ubuntu 22.04, コマンドラインでパスワードをハッシュ化する（htpasswd bcrypt, doveadm SHA-512, openssl SHA-512）

Wed, 01 Nov 2023 23:45:00 +0900

htpasswd + bcrypt

$ sudo apt install apache2-utils

$ sudo apt list --installed apache2-utils
apache2-utils/jammy-updates,now 2.4.52-1ubuntu4.6 amd64 [installed]

$ htpasswd -nB myuser
New password: password
Re-type new password: password
myuser:$2y$05$aw7xqaxQ207POKX8bavQleo52mb1jxRT7WenwvXqW21FA4wnygHjq

password - Compute bcrypt hash from command line - Unix & Linux Stack Exchange

doveadm + SHA-512

$ sudo apt install dovecot-core

$ sudo apt list --installed dovecot-core
dovecot-core/jammy-updates,now 1:2.3.16+dfsg1-3ubuntu2.2 amd64 [installed]

$ doveadm pw -s SHA512-CRYPT
Enter new password: password
Retype new password: password
{SHA512-CRYPT}$6$jtT1Mdke./dCtWSp$5ptqP0pgduBjHiRHCfh0nrWstAI46Jmytf88VlrJgpMsBPSNVhFG1cdgxkHVAXLporwb0d9pcYskAfFPqdtEy1

security - How to create SHA512 password hashes on command line - Unix & Linux Stack Exchange

openssl + SHA-512

$ sudo apt list --installed openssl
openssl/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.12 amd64 [installed]

$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

$ openssl passwd -6
Password: password
Verifying - Password: password
$6$TmbOcErpIJRy.gWH$phJqAZzmdBj206D4kQEJNEq638KJyUwcnLbK61yBQeVsImjIg0SYXeClDjyMFCVCAvjqeNszhwtz1aUtTPKo70

Ubuntu コマンドの実行を1度だけスケジュールする（atコマンド）

Wed, 28 Jun 2023 19:15:00 +0900

sudo apt install at

コマンドは/bin/shで実行される。

次の18:00に1度だけコマンドを実行

echo 'wondershaper clear eno1' | sudo at 18:00

2023年6月29日 18:00に1度だけコマンドを実行

echo 'wondershaper clear eno1' | sudo at 18:00 2023-06-29

実行スケジュール（ジョブ一覧）を確認する

sudo at -l

ジョブ1番の実行スケジュールをキャンセルする

sudo at -d 1

https://yuya-hirooka.hatenablog.com/entry/2021/01/22/215657

Ubuntu ネットワーク帯域を制限する（Wondershaper）

Wed, 28 Jun 2023 19:15:00 +0900

sudo apt install wondershaper

# 上下300kbpsに制限
sudo wondershaper eno1 300 300
sudo wondershaper enp0s31f6 300 300

# 下り1000kbps、上り300kbpsに制限
sudo wondershaper eno1 1000 300
sudo wondershaper enp0s31f6 1000 300

# 帯域制限を解除
sudo wondershaper clear eno1
sudo wondershaper clear enp0s31f6

https://askubuntu.com/questions/20872/how-do-i-limit-internet-bandwidth

rootユーザで/bin/shによるコマンド実行をスケジュール（atコマンド）

echo "wondershaper eno1 300 300" | sudo at 18:00 2023-06-29
echo "wondershaper clear eno1" | sudo at 2:00 2023-06-29

Ubuntu ネットワーク通信量をターミナルからグラフで見る（Speedometer）

Fri, 19 May 2023 09:30:00 +0900

Ubuntu Server 22.04

sudo apt install speedometer

通信量を見たいネットワークデバイスの名前を調べる（eno1、enp0s31f6、enp3s0、eth0、wlan0など）。

ip addr

eno1を目的のデバイスの名前に置き換えて、以下のコマンドを実行する。

speedometer -l -r eno1 -t eno1 -m $(( 1024 * 1024 * 3 / 2 ))

# other examples
speedometer -l -r enp0s31f6 -t enp0s31f6 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r enp3s0 -t enp3s0 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r eth0 -t eth0 -m $(( 1024 * 1024 * 3 / 2 ))

speedometer -l -r wlan0 -t wlan0 -m $(( 1024 * 1024 * 3 / 2 ))

参考

networking - How to display network traffic in the terminal? - Ask Ubuntu

Jenkinsのapt GPGキーを更新する

Mon, 17 Apr 2023 09:00:00 +0900

$ sudo apt update

Err:9 https://pkg.jenkins.io/debian-stable binary/ Release.gpg
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://pkg.jenkins.io/debian-stable binary/ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA
W: Failed to fetch https://pkg.jenkins.io/debian-stable/binary/Release.gpg  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA
W: Some index files failed to download. They have been ignored, or old ones used instead.

自宅サーバのDocker NetworkのIPアドレスプールが枯渇した

Thu, 26 Jan 2023 04:00:00 +0900

https://twitter.com/aoirint/status/1617993934625722368

弊自宅サーバでは、サーバソフトウェアや定期実行プログラムのデプロイに、基本的にDocker Composeを使用しています。

先日、新しいソフトウェアをDocker Composeでデプロイしようとして、以下のエラーが発生しました。

Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

Docker Networkが使用するIPアドレスプールが枯渇し、新しいIPアドレスブロックを確保できなかったという内容のエラーです。

環境

Ubuntu 20.04

$ docker -v
Docker version 20.10.23, build 7155243

$ docker compose version
Docker Compose version v2.15.1

原因

このエラーは、30個程度のDocker Networkを作成すると発生するようです。

Docker Composeでは通常、プロジェクト1つあたり、1つのDocker Networkが作成されます（複雑なプロジェクトでは、2つ以上使用することがあるかもしれません）。手元の環境では、Docker Composeのプロジェクトが27個稼働しており、28個目のプロジェクトを起動したときにエラーが発生しました。

Docker Networkの一覧は、以下のコマンドで確認できます。

docker network ls

Docker NetworkのIPアドレスには、いわゆるプライベートIPアドレスの範囲が使用されます。

プライベートIPアドレスの範囲は、以下のようになります（CIDR表記）。

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

作成されたDocker Networkに割り当てられたIPレンジはdocker network inspectコマンドで確認できます。以下の記事で紹介されているコマンドが便利です。

HashiCorpのapt GPGキーを更新する

Wed, 25 Jan 2023 04:00:00 +0900

$ sudo apt update

Err:2 https://apt.releases.hashicorp.com focal InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://apt.releases.hashicorp.com focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701
W: Failed to fetch https://apt.releases.hashicorp.com/dists/focal/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701
W: Some index files failed to download. They have been ignored, or old ones used instead.

https://developer.hashicorp.com/terraform/cli/install/apt

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

gpg --no-default-keyring --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg --fingerprint

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

自宅ネットワークのbind9をdocker composeに移行した

Wed, 25 Jan 2023 03:40:00 +0900

自宅ネットワークのbind9をdocker compose化したので記録。
これまでホストで直接動かしていたけれど、OOM Killerか何かに3,4日に1度くらいでキルされていたので不便だった
これでdocker composeのrestart機構で再起動がかかるようになる
- systemdのrestart機構ワカラナイ
Dockerイメージ: https://hub.docker.com/r/ubuntu/bind9

コード

docker-compose.yml

services:
  bind9:
    image: ubuntu/bind9:9.18-22.04_beta
    restart: always
    ports:
      - "0.0.0.0:53:53/udp"
    volumes:
      - "./volumes/bind_etc/named.conf.local:/etc/bind/named.conf.local:ro"
      - "./volumes/bind_etc/named.conf.options:/etc/bind/named.conf.options:ro"
      - "./volumes/bind_var_cache:/var/cache/bind:rw"
      - "./volumes/bind_var_lib:/var/lib/bind:rw"
    environment:
      - "TZ=Asia/Tokyo"
      - "BIND9_USER=bind" # UID=101

volumes/bind_etc/named.conf.options

acl my-network {
  10.0.0.0/8;
  172.16.0.0/12;
  192.168.0.0/16;
  localhost;
};

options {
  directory "/var/cache/bind";
  response-policy { zone "rpz"; };

  allow-query { any; };
  allow-recursion { my-network; };
  allow-query-cache { my-network; };

  dnssec-validation auto;

  forward only;
  forwarders {
    # ISP DNS1;
    # ISP DNS2;
    8.8.8.8;
    8.8.4.4;
    1.1.1.1;
  };
}

volumes/bind_etc/named.conf.local

zone "example.com" IN {
  type master;
  file "example.com.zone";
};

zone "rpz" {
  type master;
  file "rpz.zone";
  allow-query { none; };
};

volumes/bind_var_cache/example.com.zone

$ORIGIN example.com.
$TTL    3600
@      IN     SOA   ns.example.com.   root.example.com (
    2023012500      ; Serial
    3600            ; Refresh
    900             ; Retry
    604800          ; Expire
    86400           ; Minimum
)

      IN     NS    ns.example.com.
ns     IN     A     127.0.0.1

@      IN     A     127.0.0.1
sub    IN     CNAME example.com.

volumes/bind_var_cache/rpz.zone

$TTL    3600
@       IN     SOA   localhost. root.localhost. (
    2023012500      ; Serial
    3600            ; Refresh
    900             ; Retry
    604800          ; Expire
    86400           ; Minimum
)

        IN     NS    localhost.

; block malicious domains
malicious.example.com A 0.0.0.0

既知の問題

libvirt dnsmasqが53/udpを先に取ると動かなくなりそう？

ホストのbind9をアンインストール

sudo apt purge bind9
sudo rm -rf /var/cache/bind/

OpenVPNとnginxをOpenVPNのPort Share機能で共存させる

Wed, 19 Oct 2022 00:50:00 +0900

TCP 443番ポートは、一般にHTTPSの通信に使われ、ファイアウォールやプロキシによる制限の強いネットワークでも通過できることが多い。一方、WebサーバをホストしたいIPアドレスと、443番ポートでVPNをホストしたいIPアドレスが同一の場合、443番ポートの取り合い（ポート番号の重複）が起きてしまう。

OpenVPNには、OpenVPNが待ち受けるポートへの通信が、 VPNのパケットか、VPN以外のパケット（例えばnginxへのHTTPS通信）かを自動で判別して、 VPN以外のパケットを中継してくれるPort Share機能がある。

つまり、OpenVPNが443番（0.0.0.0:443）で待ち受け、 nginxは他の適当なポート（例えば127.0.0.1:4443）で待ち受けるようにして、 Port Share機能の転送先をnginxに設定すれば、443番で待ち受けるOpenVPNと、本来443番で待ち受けたいnginxとが共存できる。

UbuntuサーバへのOpenVPNの導入は、以下のDigitalOceanの記事が有用なので、参照されたい。

OpenVPNで使用するサーバー証明書・クライアント証明書を発行するCAサーバをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-a-certificate-authority-ca-on-ubuntu-20-04
OpenVPNをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04-ja

OpenVPNのインストールにあたっての重要な点として、 ステップ7 — OpenVPNの設定の（オプション）DNSの変更をプッシュして、VPNを介してすべてのトラフィックをリダイレクトするを実行した上で、 ステップ9 — ファイアウォールの設定を手順通り実行することがある。 NAT下にあるなどの理由でufwの設定をしていなかったサーバーでも、新たにufwの設定をすることで、トラブルなくOpenVPNのインストールができる。このステップを行わないと、VPN外へのパケットの転送が動作せず、VPN接続中のクライアントがインターネットに接続できない状況に陥る。

また、（オプション）ポートとプロトコルの調整で、待ち受けポートを443番、プロトコルをTCPにしておく。 OpenVPNの起動の際には、nginxとポート番号を取り合って起動に失敗しないように、nginxをあらかじめ停止し、ポート番号を書き換えておく。

nginx 設定ファイル

/etc/nginx/sites-enabled/などにあるnginxの設定ファイルを書き換え、 4443番で待ち受けるようにする。

server {
  listen 4443 http2 ssl;
}

大量にサイトをホストしている場合、コマンドやVSCodeなどでまとめて書き換えるとよい。

/etc/openvpn/server/server.conf

OpenVPNのサーバー設定ファイルにport-shareを追記する。

port 443
port-share 127.0.0.1 4443

proto tcp

OpenVPNからnginxへのパケット転送の許可（ufw）

ufw allow from 10.8.0.0/24 to any port 4443

nginx, OpenVPNの再起動

nginxおよびOpenVPNを再起動し、443番ポート宛てのHTTPS通信（nginx宛て）、443番ポート宛てのVPN接続（OpenVPN宛て）が正常に動作することを確認する。

nginx, リバースプロキシからのReferrer-Policyヘッダを置換する

Fri, 01 Jul 2022 09:00:00 +0900

add_header Referrer-Policy no-referrer;
# add_header Referrer-Policy same-origin;

proxy_hide_header Referrer-Policy; # remove Referrer-Policy from original response

Mastodon

Mastodonでリファラを送らないようにしたかった。

HTMLタグのmetaタグを使う方法をよく使うのだけれど、ブログとかによくあるheadタグへの任意HTML追加機能のようなものは Mastodon v3.5.3にはなさそうだった。

https://github.com/mastodon/mastodon/issues/9183

同一オリジンでもリファラを送らないようにする（no-referrer）とMastodonの一部の設定が更新できなくなくなるようなので、 MastodonではReferrer-Policy: same-originに設定した。

単純にadd_headerするだけだと、Mastodonが返すReferrer-Policyとnginxが追加するReferrer-Policyで2つのヘッダになってしまった。

referrer-policy: origin
referrer-policy: no-referrer

そこで、

proxy_hide_header Referrer-Policy;

でMastodonから返ってきたReferrer-Policyを削除するようにした。

あとは、

add_header Referrer-Policy same-origin;

するだけ。

https://mstdn.aoirint.com/@aoirint/108569086590516035

Let's Encrypt Failure Rate Limit

Thu, 16 Jun 2022 15:52:00 +0900

設定に自信がないときは、Rate limitが緩いLet’s EncryptのStaging環境で試してから本番環境でやり直す Staging環境を使うには、certbotのオプションに --test-cert をつける

本番環境の場合、1時間内に5回失敗すると一時的に弾かれるようになる（too many failed authorizations recently） Staging環境の場合、1時間内に60回失敗まで緩められている

本番環境
- https://letsencrypt.org/docs/rate-limits/
Staging環境
- https://letsencrypt.org/docs/staging-environment/

Use MinIO with AWS CLI

Fri, 10 Jun 2022 02:31:00 +0900

AWS S3互換を意識して、設定にあたってMinIOに依存しすぎないようにしたい（それはそれとしてMinIO ClientはAWS S3互換クライアントとして便利らしい）

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
aws-cli version: 2.7.7

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/index.html

--endpoint-urlで操作対象をAWS S3からMinIOに変更できる

https://awscli.amazonaws.com/v2/documentation/api/latest/topic/config-vars.html

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS以外の認証情報を~/.aws/credentialsに保持するのもいまいちな感があるので、環境変数に設定することにする
（AWSのIAM？がどうなってるのかよくわからんけど、本来マニュアルオペレーションするときはAWSのアカウントで認証するのかな？）

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-s3-commands.html

まずは特権アクセスでBucketを作る
MinIOのrootユーザのユーザ名・パスワードを設定する（MINIO_ROOT_USER、MINIO_ROOT_PASSWORD）

export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=minioadmin

Bucket一覧

aws --endpoint-url http://127.0.0.1:9000 s3 ls

Bucket作成（create-bucketも大して変わらんと思うので、あえて高レベルAPIのs3 mbを使わなくていい気もするけどまあいいでしょう）

aws --endpoint-url http://127.0.0.1:9000 s3 mb s3://mybucket

アクセス制御（Policy）周りはS3と一部互換性がない
Policyの構文自体はほぼ同じに作られているけれど、仕様が違うように思われる（AWS S3の仕様をよく知らんけど）

https://github.com/minio/minio/issues/9530#issuecomment-625883667

Bucket policyはパブリックアクセスのルール、User/ServiceAccount Policyは認証付きルールと使い分ければいいと思われる
Bucket policyはAWS S3互換APIから設定できる
User/ServiceAccount PolicyはAWS互換APIから設定できないのでWeb UIまたはMinIO Clientから設定する

Bucket policy: allow anonymous user (public) to read mybucket/*

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "*"
        ]
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::mybucket/*"
      ]
    }
  ]
}

PrincipalはMinIO上のBucketとしては意味がないと思うが、Web Consoleでいじると必要だといわれるので付けておく

PIDから対応するdockerコンテナを見つける

Sun, 22 May 2022 15:30:00 +0900

docker-pidパッケージが便利
- https://www.glia-computing.com/blog/listing-process-ids-on-docker-containers/
- https://github.com/masatanish/docker-pid
- pip3 install docker==5.0.3 docker-pid==0.0.3

Self-hosted GitLab Runnerで安全にdockerを扱えるようにするためにどうしたらいいかわからない

Tue, 10 May 2022 12:47:51 +0900

適当に検索すると、ホストへの特権昇格を許す設定ばかり見かける。自分だけしか使わないならば構わないかもしれないけれど、なんらかのCIを実行する権限さえあれば、ホストのroot権限をとれるというのは危険だと思う。（コードレビュー必須でPRではマージ済みのCIが実行されるならいいのか…？）

GitLabの公式Shared Runnerがやっているように、docker-machineを使うのがいいはず。おそらくdocker入りの仮想マシンをCIジョブごとに立てて、privilegedなコンテナからブレイクアウトしても仮想マシンの外に出られないようになっていると思う。 GitLabはいろいろオープンなので、実際のShared Runnerの構成・設定が公開されている。たいへん助かる。

https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html

のだけれども、GCPでこれを稼働させるのはちょっと費用面がよくわからない…。

ツリー
- https://twitter.com/aoirint/status/1523826104343343105
- https://twitter.com/aoirint/status/1524426103615500288

Windows hostsファイルを編集する

Mon, 07 Feb 2022 12:12:18 +0900

管理者PowerShellに以下を貼り付ける。

notepad C:\WINDOWS\system32\drivers\etc\hosts

Windows シンボリックリンクを作成する

Mon, 07 Feb 2022 12:12:18 +0900

管理者cmdで実行する。

; ファイル
mklink C:\link C:\original

; ディレクトリ
mklink /D C:\link C:\original

PostgreSQL 13 ユーザ（ロール）のパスワード変更

Sun, 06 Feb 2022 09:36:47 +0900

psql --user myuser postgres

ALTER ROLE myuser WITH PASSWORD 'new_password';

PostgreSQL 13 データベースの名前変更

Sun, 06 Feb 2022 09:36:47 +0900

psql --user myuser postgres

ALTER DATABASE mydatabase RENAME TO new_mydatabase;

Ubuntu 20.04, ネットワーク設定変更時の認証を回避する

Mon, 29 Nov 2021 20:30:00 +0900

Ubuntu 20.04にアップデートしてから、ネットワーク設定の変更時（接続のON/OFFなど）にSystem policy prevents control of network connectionsと表示され、認証を要求されるようになりました。

ここまではまだいいのですが、認証が表示されるたびに数秒間デスクトップがハングする状態になっていて、ストレスでした。 Keyringのロックを解除するときも数秒間ハングするので、似た原因がありそうです。

ひとまず、設定変更時の認証を要求されないようにして、ハングを防ぐことを試みました。結果として試みは成功し、ハングを回避できるようになりました。

/etc/polkit-1/localauthority/50-local.d/50-allow-network-manager.pkla

[Allow Network Manager all Users]
Identity=unix-user:*
Action=org.freedesktop.NetworkManager.settings.modify.system;org.freedesktop.NetworkManager.network-control
ResultAny=no
ResultInactive=no
ResultActive=yes

systemctl restart network-manager.service

Ubuntu 20.04, Unattended Upgradesを停止

Mon, 08 Nov 2021 07:30:00 +0900

https://unix.stackexchange.com/questions/470709/how-do-i-stop-disable-unattended-upgrades-from-being-launched-automatically

勝手にnvidia driverの更新が走って、カーネルに読み込まれているdriverバージョンと、ディスク上にあるdriverバージョンが一致しなくなって、デスクトップアプリが起動しなくなったりする。

どうせ結構な頻度でapt upgradeするし、再起動が保証されないタイミングで更新されて、不安定になるのはいただけない。

sudo dpkg-reconfigure -plow unattended-upgrades

これでTUIが起動するので、<No>を選ぶ。

cron

Fri, 05 Nov 2021 02:00:00 +0900

Linux上でプログラムの実行をスケジュールするためのプログラム。

独自の書式をもつcrontabファイルでスケジュールを設定する。

想定環境

Ubuntu 20.04

/etc/crontab

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 * * * * root    cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

crontabの時刻形式は独特で、複雑な設定を新しく書き起こすのは面倒くさい。

PulseAudioでSSHサーバ側の音声をクライアント側で再生する

Sat, 09 Oct 2021 20:00:00 +0900

RDPと違い、VNCでは接続先の音声を送れないことがある。

接続先のデスクトップ（SSH・VNCサーバ）で再生された音声をSSH経由で送信し、SSH・VNCクライアント側で再生できるようにする。

https://raspberrypi.stackexchange.com/questions/8621/how-to-set-up-a-pulseaudio-sink
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-tunnel-sink-new
- module-tunnel-sink-newの実装はすでにmodule-tunnel-sinkで動くようになっている（pulseaudio 13.99.1）

音声を受け取る側（SSH・VNCクライアント、PulseAudioサーバ）

受信側 /etc/pulse/default.pa

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.0/8

load-module module-null-sink sink_name=DummyOutputRemote0 sink_properties=device.description="DummyOutputRemote0"
load-module module-loopback source=DummyOutputRemote0.monitor source_dont_move=true

DummyOutputRemote0に対して音声が送られてくる。

DummyOutputRemote0.monitorで入力として音声を拾うこともできる。

受信側 ~/.ssh/config

Host your-server
    # VNC
    LocalForward 15900 localhost:5900
    # PulseAudio
    RemoteForward 14713 localhost:4713

音声を送る側（SSH・VNCサーバ、PulseAudioクライアント・サーバ＝中継用）

送信側 /etc/pulse/default.pa

load-module module-tunnel-sink sink_name=Remote server=tcp:127.0.0.1:14713 sink=DummyOutputRemote0

PulseAudio再起動（pulseaudio -k）後、接続先のデスクトップ上で音声出力デバイス（Sink）をDummyOutputRemote0に設定する。 DummyOutputRemote0が表示されない場合、どこか設定が間違っていると思われる。

電源メニューから音声デバイスを変更できるようにするGNOME拡張
- https://extensions.gnome.org/extension/906/sound-output-device-chooser/

SendGrid

Sat, 11 Sep 2021 13:10:00 +0900

背景

Discourseをセットアップしようとしていたところ、いくつかのEmailプロバイダが紹介されていた。

https://github.com/discourse/discourse/blob/4e0a43f2117ac83bcf7e0f9bed65370f6c4c15bb/docs/INSTALL-email.md

Discourseはセットアップにメールサーバが要求される。以前のMastodonのセットアップでは、Gmailとアプリパスワードを使った簡易セットアップを使ったが、経験積みとセキュリティ上の懸念から、今回はメールサーバを用意することにした。

名前を聞いたことのあるSendGridを使う。業務上の利用を想定しているようだが、個人による利用として続行する。スケールする商用サービスでの利用ではないが、利用経験は技術選定の上で大事だと思う。その分、Abuseしないように考えなければならないが。

Freeプラン

https://sendgrid.com/pricing/

1日に100メールまではFreeプランが使用できる。自分しか使わない、またはごくごく小規模な利用では十分だろう。

登録

https://sendgrid.com/

Start For Freeから登録する。

細かい登録の過程は省略する。

ドメインの認証

ダッシュボードを開く。

https://app.sendgrid.com/

https://app.sendgrid.com/settings/sender_auth/domain/create

ドメインプロバイダ（DNSホスト）の選択を求められる。お名前.comはリストになかったので、Other Host (Not Listed)を選択し続行する。あまり意味はないだろうが、Which DNS Hostにプロバイダ名を書いておく。

ドメイン名を入力する。

DNSサーバに登録すべき認証用のレコードが表示される（DNSサーバにクエリを送れば誰でも確認できるので公開情報）。

ドメインプロバイダ/DNSサーバでDNSレコードを設定する。設定が反映されるまでしばらく待つ。

ドメインが認証された。これでSendGridを使って、このドメインからのメールを送信できるようになった。

APIキーの発行（送信テスト）

https://app.sendgrid.com/guide/integrate

Web APIを選択する。

プログラミング言語/利用プログラムを選択する。チュートリアルの出し分けをするだけで、ここでの選択に特に意味はないと思われる（チュートリアルなしでAPIキーを発行もできる： https://app.sendgrid.com/settings/api_keys）。

とりあえずcURLでテストすることにして、APIキーを発行する。

下のcurlコマンドの送信JSONデータを編集する。 toを自分のメールアドレス、fromを認証したドメインのメールアドレスに変える。特にfromのメールアカウントを作成する必要はなく、 hoge@example.comのように適当なアカウント名をつけたアドレスを使えばよい。

コマンドを適当な端末で実行し、メールが届けば成功。

SendGrid上でも送信成功を確認できる。

SmokePing in Docker

Sun, 22 Aug 2021 09:45:00 +0900

https://hub.docker.com/r/dperson/smokeping

Copy Configs

docker run --name smokeping --rm -d dperson/smokeping:latest
docker cp smokeping:/etc/smokeping ./config
docker rm -f smokeping

docker-compose.yml

version: '3.9'
services:
  smokeping:
    image: dperson/smokeping:latest
    restart: always
    ports:
      - '{SMOKEPING_PORT:-127.0.0.1:8000}:80'
    volumes:
      - './config:/etc/smokeping:ro'
      - './data:/var/lib/smokeping'
    environment:
      TZ: Asia/Tokyo

config/config.d/Targets

*** Targets ***

probe = FPing

menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website of xxx Company. \
         Here you will learn all about the latency of our network.

+ Home

menu = Home
title = Home Network
#parents = owner:/Test/James location:/

++ Router

menu = Router (192.168.0.1)
title = Router (192.168.0.1)
host = 192.168.0.1

++ MyServer

menu = MyServer (192.168.0.2)
title = MyServer (192.168.0.2)
host = 192.168.0.2
#alerts = someloss

透過プロキシ（macOS, go-transproxy）

Mon, 21 Jun 2021 18:40:00 +0900

環境変数

シェル起動時にネットワーク設定からプロキシ設定を環境変数に読み出すようにしている場合、GUIで設定すればOK。

export HTTP_PROXY=http://proxy.example.com:8080/
export HTTPS_PROXY=http://proxy.example.com:8080/
export NO_PROXY=localhost,127.0.0.0/8,::1

NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。

ビルド

https://github.com/wadahiro/go-transproxy

git clone https://github.com/wadahiro/go-transproxy.git
cd go-transproxy/
make

ls go-transproxy/bin/transproxy

# check network device name
ifconfig

~/transproxy/pf.conf

MacBookの無線LANカード：en0

Mac miniなどの場合はNIC名が異なる場合があるので注意。

Packets = "proto tcp from en0 to {!192.168.0.0/16}"
rdr pass log on lo0 $Packets port 80 -> 127.0.0.1 port 3129
rdr pass log on lo0 $Packets port 443 -> 127.0.0.1 port 3130
pass out on en0 route-to lo0 inet $Packets port {80, 443} keep state

有効化

sudo pfctl -ef ~/transproxy/pf.conf
transproxy -disable-iptables

無効化

# stop transproxy process (Ctrl+C)

# reset pf configs
sudo pfctl -df /etc/pf.conf

Macでプロキシとの戦いに疲れたので、透過型プロキシを導入してみた - Qiita

透過プロキシ（Ubuntu, go-transproxy）

Mon, 21 Jun 2021 18:10:00 +0900

/etc/sudoers

Defaults        env_keep+="HTTP_PROXY"
Defaults        env_keep+="HTTPS_PROXY"
Defaults        env_keep+="NO_PROXY"

環境変数

export HTTP_PROXY=http://proxy.example.com:8080/
export HTTPS_PROXY=http://proxy.example.com:8080/
export NO_PROXY=localhost,127.0.0.0/8,::1

NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。

デスクトップの場合はGUI設定でOK。

/usr/local/bin/transproxy

https://github.com/wadahiro/go-transproxy

/usr/local/bin/transproxy-start

#!/bin/bash

set -eu

# iptables -t nat -I OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131
# iptables -t nat -I OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131
iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129
iptables -t nat -I OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130

transproxy -disable-iptables # -dns-over-https-enabled

/usr/local/bin/transproxy-stop

#!/bin/bash

set -eu

# iptables -t nat -D OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131
# iptables -t nat -D OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131
iptables -t nat -D OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130
iptables -t nat -D OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129

iptablesのルールを書き換えるため、実行時にはroot権限が必要。

bind9

Wed, 09 Jun 2021 01:30:00 +0900

server$ sudo apt install bind9

使用中のDNSサーバの確認

クライアントに設定されているDNSサーバはnmcliコマンドで確認できる。

$ nmcli device show | grep DNS
IP4.DNS[1]:                             8.8.8.8
IP4.DNS[2]:                             8.8.4.4
IP4.DNS[3]:                             1.1.1.1

Command-line to list DNS servers used by my system - Ask Ubuntu

用語

BIND DNSサーバー構築 | CentOSサーバー構築入門

コンテンツサーバ（権威サーバ）

あるゾーン（DNSにおける名前の管理単位）に関する名前解決要求（非再帰問い合わせ）を受け取り、自身が管理するゾーンならば名前解決結果を、委任情報を持つゾーンならば委任先の権威サーバ情報を応答する。

ルートゾーン（FQDN: .）を管理するルートサーバは、TLD（例えば jp.）の権威サーバへの委任情報を持つ。

ゾーン情報において、NSレコードにより指定される。

キャッシュサーバ（フルサービスリゾルバ）

クライアントから名前解決要求（再帰問い合わせ）を受け取り、コンテンツサーバへ反復的に名前解決要求（反復問い合わせ）を送ることで任意のドメイン名の名前解決を行う。

JPRS用語辞典｜フルサービスリゾルバー（キャッシュDNSサーバー）

例えばhoge.example.jp.というドメインの名前解決要求を受け取ったとき、ルートサーバ.への非再帰問い合わせによりjp.権威サーバへの委任情報を取得する。 jp.権威サーバへの非再帰問い合わせによりexample.jp.権威サーバへの委任情報を取得する。 example.jp.権威サーバへの非再帰問い合わせによりhoge.example.jp.のIPアドレスを取得する、のような流れで反復的に問い合わせを行うことでhoge.example.jp.の名前解決を行う。

ISPの提供するDNSサーバや会社などの組織内DNSサーバ、GoogleやCloudflareなどが提供するパブリックDNSがある。

ASCII.jp：DNSによる名前解決の仕組みを理解しよう (1/2)

回送

プロキシのように、受け取った名前解決要求を他のDNSサーバに送り、応答を返す。

/etc/bind/named.conf.options

自身が管理していない情報（ゾーン、委任情報）に関する問い合わせについて、他のDNSサーバ（フルサービスリゾルバ）に問い合わせを回送するように設定する。

デフォルト設定ファイル

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

変更点

forwarders {
        8.8.8.8;
        8.8.4.4;
        1.1.1.1;
};

初歩から解説！BINDでシンプルDNSサーバー構築【構築編】｜開発者ブログ｜株式会社アイソルート

確認

server$ systemctl restart bind9.service

client$ dig @192.168.x.x aoirint.com
...
;; ANSWER SECTION:
aoirint.com.  3600 IN A 185.199.108.153
aoirint.com.  3600 IN A 185.199.111.153
aoirint.com.  3600 IN A 185.199.109.153
aoirint.com.  3600 IN A 185.199.110.153
...

digコマンドの使い方 - Qiita

/etc/bind/named.conf.local

DNSサーバの管理するゾーンの名前と対応する設定ファイル（ゾーンファイル）を設定する。

Ubuntu/Raspberry Pi/Debianの時刻ずれを解消する

Sun, 04 Apr 2021 06:00:00 +0900

$ sudo apt update
Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:2 http://archive.raspberrypi.org/debian buster InRelease [32.9 kB]
Reading package lists... Done  
E: Release file for http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease is not valid yet (invalid for another 27d 15h 31min 39s). Updates for this repository will not be applied.
E: Release file for http://archive.raspberrypi.org/debian/dists/buster/InRelease is not valid yet (invalid for another 26d 5h 35min 24s). Updates for this repository will not be applied.

こういうエラーが出ることがある（ログはRaspberry Pi OS）。

sudo timedatectl set-timezone Asia/Tokyo
sudo date --set 2021-04-04
sudo date --set 06:00

まずは手動でタイムゾーンと時刻を合わせる（だいたいでOK）。

SSH Port Forwardingを使ってNAT間で通信するPort Proxy Server in Docker

Sun, 21 Mar 2021 03:32:29 +0900

SSHポートフォワーディング：踏み台による中継接続

SSHポートフォワーディングには、ローカルポートフォワーディング、リモートポートフォワーディングの2種類があります。

sshポートフォワーディング - Qiita

ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、ホストYがホストZにSSH接続することで、ホストXのWebサーバのネットワークポートに、ホストYの指定したポートから接続できるようになります（「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。

user@hostY.networkB.example: $ ssh user@hostZ.networkA.example -L "127.0.0.1:10080:hostX.networkA.example:80"

user@hostY.networkB.example: $ wget http://127.0.0.1:10080/index.html
I am "hostX.networkA.example:80".

リモートポートフォワーディングでは、 SSHクライアント側から見えるネットワークポートを SSHサーバ側に転送することができます。先の例でいうと、ホストXがネットワークBに接続していて、ファイアウォール（NAT）によってネットワークAにあるホストZから接続できないとき、ホストYがホストZにSSH接続することで、ホストZからホストXに接続できるようになります。

user@hostY.networkB.example: $ ssh user@hostZ.networkA.example -R "127.0.0.1:10080:hostX.networkB.example:80"

user@hostZ.networkA.example: $ wget http://127.0.0.1:10080/index.html
I am "hostX.networkB.example:80".

この方法は、ネットワーク内のあるホストにSSH接続ができる環境さえあれば、 VPNや他のTCPプロキシをセットアップするより簡単に隠されたネットワークにアクセスすることができるように思います。

ポートプロキシサーバ：2種類のSSHポートフォワーディングの組み合わせ

ここで、別の構成のネットワークについても考えてみます。新しくネットワークCを導入して、ホストXはNAT内のネットワークC（hostX.networkC.example）、ホストYはNAT内のネットワークB（hostY.networkB.example）、ホストZはネットワークB、Cからともに接続可能なネットワークA（hostZ.networkA.example）という構成を考えてみます。

この構成で、ホストYからホストXに接続可能な環境を作るには、次のような手順が考えられます。

ホストXからホストZにSSH接続し、リモートポートフォワーディングによってホストZ上の"ポートQ"をホストX上の"ポートP"に転送する
ホストYからホストZにSSH接続し、ローカルポートフォワーディングによってホストY上の"ポートR"をホストZ上の"ポートQ"に転送する

これにより、ホストYは、自身のポートRを使って、ホストXのポートPに接続することができます。もしホストXに物理的にアクセスできない環境でも、あらかじめホストXをホストZに常時接続するように設定しておけば、その接続（ポートQからポートPへの転送）が生きている限り、好きなタイミングでホストYからホストXに接続（ポートRからポートQへの転送、すなわちポートRからポートPへの転送）することができます。

SSH Port Forwardingを使ったPort Proxy Server in Docker

前項のポートプロキシサーバの問題として、次の3つを考えました。

Debianパッケージから内容物を抽出する

Tue, 08 Dec 2020 22:40:00 +0900

Debian – buster の bash パッケージに関する詳細
- http://ftp.jp.debian.org/debian/pool/main/b/bash/bash_5.0-4_amd64.deb

wget http://ftp.jp.debian.org/debian/pool/main/b/bash/bash_5.0-4_amd64.deb
mkdir bash
tar xvf bash_5.0-4_amd64.deb -C bash/
cd bash
mkdir data
tar xvf data.tar.xz -C data/

cd data
# here is root directory

Dockerイメージから内容物を抽出する

Tue, 08 Dec 2020 22:30:00 +0900

docker save | Docker Documentation

docker pull alpine:3
docker save -o out.tar alpine:3
mkdir out
tar xvf out.tar -C out/
cd out/6709f754bd0ccbbea9a7481e92772a494cca1543b3421978edff62bc5de16662
tar xvf layer.tar -C layer/

cd layer
# here is root directory

Docker + Docker Compose on Vagrant Ubuntu Server

Thu, 22 Oct 2020 16:30:00 +0900

kvm (qemu)を使うこともできるらしいが、対応したboxを用意する必要があるのでVirtualBoxを使う。

KVM用仮想マシンをVagrantで手軽に作る | さくらのナレッジ

Commands

# 起動
vagrant up

# 削除
vagrant destroy

# ssh
vagrant ssh

# 停止（シャットダウン）
vagrant halt

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/bionic64"
  config.vm.hostname = "ubuntu-docker"

  # config.vm.network "forwarded_port", guest: 80, host: 8080
  # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1"

  config.vm.provider "virtualbox" do |vb|
    vb.name = "ubuntu-docker"
    vb.memory = "1024"
    # vb.gui = true
  end

  config.vm.provision "shell", inline: <<-SHELL
    apt-get update

    apt-get install -y \
      apt-transport-https \
      ca-certificates \
      curl \
      gnupg-agent \
      software-properties-common

    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

    add-apt-repository -y \
      "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) \
      stable"

    apt-get update

    apt-get install -y \
      docker-ce \
      docker-ce-cli \
      containerd.io

    curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
    chmod +x /usr/local/bin/docker-compose

    adduser vagrant docker
  SHELL
end

Ubuntu プロキシ設定

Fri, 02 Oct 2020 15:40:00 +0900

User (Desktop): Settings > Network > Network Proxy

Settings > Network > Network Proxy > Manualに設定する。自動的に環境変数HTTP_PROXY, HTTPS_PROXYにスキームが追加された状態で設定される。

HTTP Proxy: proxy port
HTTPS Proxy: proxy port
Ignore Hosts: localhost, 127.0.0.0/8, ::1（プライベートネットワーク・組織内ネットワークのIPアドレス範囲またはドメインも追加する）

curlやwget、pipなど主要コマンドは注意点として、別ユーザとしてコマンドを実行すると環境変数が引き継がれない。例えばsudo curlしたときにプロキシに接続しにいかない。

/etc/sudoers

sudoでコマンドを実行したとき、実行時シェルに設定されている環境変数を引き継ぐようにする。 sudoersは書き込み禁止になっているためvisudoで編集する。

# run as root
visudo -f /etc/sudoers

Defaults env_keep+="HTTP_PROXY"
Defaults env_keep+="HTTPS_PROXY"
Defaults env_keep+="NO_PROXY"
Defaults env_keep+="EDITOR"

/etc/environment

システム全体の環境変数として設定される。影響範囲が大きいので注意。デスクトップユーザではSettings側の設定（Disabledなら設定されない）が優先されるようだった。

HTTP_PROXY=http://proxy:port
HTTPS_PROXY=http://proxy:port
NO_PROXY=localhost, 127.0.0.0/8, ::1

apt: /etc/apt/apt.conf

Acquire::http::proxy "http://proxy:port";                             
Acquire::https::proxy "http://proxy:port";

Snap: systemctl edit snapd.service

/etc/systemd/system/snapd.service.d/override.confにsystemdの設定ファイルを作成する。

docker-compose run --rm終了時に他のコンテナも削除する

Mon, 28 Sep 2020 10:10:00 +0900

docker-compose run --rm appを実行するとサービスappが起動してコンテナが作られ、実行が終わり次第コンテナは削除される。このとき削除されるコンテナはforegroundで実行されたもののみで、 depends_onなどの設定からリンクを通じて起動した他サービスのdetachedコンテナは削除されず残り続ける。

docker-compose run <container> –rm does not rm links · Issue #2791 · docker/compose

このissueでlinked containersを同時に削除する機能について議論されているが、 runコマンドにオプションを増やしたくない、ということで却下されている。

As mentioned in this thread, docker-compose rm -f –all and docker-compose down already allow cleaning up a project’s containers / resources. We won’t overload run with more options at that point.

ひとまずdocker-compose run終了後にdocker-compose downを実行するシェルスクリプトで対応する。

compose_run.sh

#!/bin/bash

docker-compose run --rm "$@"
EXIT_CODE=$?
docker-compose down
exit $EXIT_CODE

Ubuntu 18.04のKernelをアップデートした（HWE Kernel）

Mon, 21 Sep 2020 00:00:00 +0900

環境の整理を兼ねて、UbuntuのKernelのアップデートをしたので、そのときのメモ。

メイン Ubuntu 18.04のKernelをアップデートした（HWE Kernel）

カーネルバージョンについて

/lib/modulesを見る限りインストール時のバージョンは4.10.0-28で、 /usr/srcを見る限り4.15.0-115をしばらく使ったあと、 4.16.18に更新していた。

バージョン4.10.xはおそらくUbuntu 16.04をクリーンインストールしたときのもので、バージョン4.15.xはdist-upgradeでUbuntu 18.04にアップデートしたときに変更されたと思われる。その後ソフトウェア導入のためのバージョン合わせかなにかで4.16.xにして、そのまま使っていた。

4.15.xから4.16.xにアップデートするときにはUKUU（Ubuntu Kernel Update Utility）を使っていた。このとき参考にしたサイト： Upgrade Kernel on Ubuntu 18.04 – Linux Hint

ところで、カーネルバージョンの後ろに付いているハイフン以降の数字はUbuntu Release ABIというらしいのだが、 UKUUを使ってカーネルをインストールするとこの部分がバージョン番号（ハイフンの前）を6ケタの数字に直したようなものになるので、これはABIとは違いそうだ（ABIは0から255までの範囲のように思われる）。 ABIのドキュメントらしきものがあったので、機会があれば読みたい：KernelTeam/BuildSystem/ABI - Ubuntu Wiki

UKUUとセキュリティアップデートについて

通常の方法でインストールされるカーネルを使っている場合、 Linux Kernelに脆弱性が発見されてもこのようにUbuntu側からセキュリティアップデートが提供される。

GPU PC (Desktop) のセットアップメモ

Fri, 18 Sep 2020 20:00:00 +0900

Ubuntu 18.04.5 LTS (Bionic Beaver)

Ubuntu 18.04、Windows 10のデュアルブート環境を構築する。プロキシ下を想定しているので、不要な場合は適宜調整。

時刻ずれの解消

Linux環境設定/デュアルブートのWindows時刻をUTCにする - Linuxと過ごす

デュアルブート環境では、BIOSの時刻を介してWindows側の時刻管理（ローカル時間）とUbuntu側の時刻管理（UTC時間）が衝突して、タイムゾーンの時差分、時計がずれてしまう。ここでは、Windows側の時刻管理をUTC時間にするようにレジストリを変更して対処する。

Windows上で管理者権限でコマンドプロンプトを起動し、以下のコマンドを実行する。

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

NTPサーバの設定（プロキシ環境）

時刻同期のためプロキシ内のNTPサーバを設定する。

Settings > Details > Date & Timeで使われるNTPサービスはsystemd-timesyncd。

nginx basic auth, reverse proxy, static files

Fri, 27 Mar 2020 10:30:13 +0900

Basic auth

Nginx で Basic 認証 - Qiita

        auth_basic "Authentication Required";
        auth_basic_user_file DIRECTORY/.htpasswd;

Reverse proxy

Nginxによるリバースプロキシの設定方法 - Qiita

        proxy_set_header HOST $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
                proxy_pass http://localhost:8000;
        }

Static files

Nginxの静的ファイル配信でハマった - shoya.io

        location /static/ {
                root PARENT_OF_STATIC_DIRECTORY;
        }

Let's Encrypt certbot Error Ubuntu（ImportError: cannot import name 'constants'）

Fri, 27 Mar 2020 10:09:41 +0900

間違えてOSのパッケージリポジトリからcertbotを入れてしまった.

コマンド

sudo certbot --nginx

エラー1（初期状態）

ImportError: cannot import name 'constants'

エラー2（pip3 uninstall certbotの後）

AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01Response'

Certbot - Ubuntubionic Nginx

sudo pip3 uninstall certbot acme
sudo apt purge certbot python-certbot-nginx

# HERE: register official ppa repository (see official guide)

sudo apt install certbot python-certbot-nginx

systemd service

Thu, 19 Mar 2020 06:32:01 +0900

テンプレート（一般ユーザ権限、bashrc使用）

[Unit]
Description=My Service

[Service]
Type=simple
User=user
Group=user
Restart=always
WorkingDirectory=WORKING_DIR
ExecStart=/bin/bash -c "COMMAND"

[Install]
WantedBy=multi-user.target

sudo ln -s my_service.service /etc/systemd/system/
sudo systemctl enable my_service
sudo systemctl restart my_service

# After you edit service file
sudo systemctl daemon-reload

# Check log
sudo systemctl status my_service

If you are using python, maybe you need to set environment PYTHONUNBUFFERED=1 to see log.

# In [Service] Section
Environment="PYTHONUNBUFFERED=1"

Environment="KEY=VALUE"

Ubuntu, add user to group

Sun, 15 Mar 2020 10:39:03 +0900

usermod -aG GROUP USER
adduser USER GROUP

https://qiita.com/orangain/items/056db6ffc16d765a8187

SSD換装時のOS移動（スケールダウン）

Wed, 29 Aug 2018 04:09:07 +0900

容量の小さなSSDに換装する（HDD 500GBからSSD 250GB）。

対象のHDD, SSD以外でUbuntuを起動（USBブートなど）
GPartedで必要なパーティションをHDDからSSDにコピー（Boot, OSとか）
コピー先でパーティションを右クリック、Manage Flagsからコピー元のパーティションとFlagsを一致させる
Ubuntuとのデュアルブートにしていたため、EFIをマウントして"ubuntu"を削除