---
# System prepended metadata

title: ICTSC2020 本戦

---

# ICTSC2020 本戦

https://contest.ictsc.net/problems
チーム名: elab
パスワード: 7KT3rMucFc

[TOC]


## 事前作業

### 踏み台サーバにssh-copy-id

パスワードログインは面倒なので鍵を登録してしまう(?)
パスワードログイン: `7KT3rMucFc`

`ssh user@103.202.216.16 -p 20008`

## 鍵一覧

```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHrWpQSq+z1Rb19+cPS+nuQAYWwl7I/IHILDuCkfXDoK akky.supernova@gmail.com
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCoTMt6Hnr/7o6pAueCEEgmA84aXAMSkatzuChQLkqurBADrPmo4DlXWJKnH6muRN5pWy2ym0jAMQKo4xq+wEve2mCtT8K9Us/6Y9+jAsdaSJquCEq3HOhwsKdX6Tj1yi9w3TP+hA34qaZgpjf421XoTM15ivYTiScc2yCw3m92u577H0f4q54GCr+SopAL9QoPYOyNcJKluBj2pf9zHZG10GNi4dp+81tq/1bT2cKB1rD4omUsbVsIDYjUUBFH0o3o6l6eo19MMe81zMwMQ6i+A8VyxIOExNRdBG1ckSE0hKn3KIHudK40di6Z82MSkVWyxJKW7OQBtZO4qRnR9ON9 hyuga@hyuga-SP3
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDIwe8kFMjPx+DWRsFwXyz0aybPpYno/B52FS0O+wr7O hide@hide-H5-CML
```

## テンプレ
```
お世話になっております。〇〇です。

この問題ではxxxxxが原因でトラブルが発生したと考えられました。
そのため、以下のように設定を変更し、○○が正しく動くことを確認いたしました。
確認のほどよろしくお願いします。


## 手順

### 1. /etc/hoge/hoo.bar の編集
```
# 2日目

## それなんて読むの?(10)

## あれ、、、おかしい(100) 


お世話になっております。elabです。

Client, R1, R2からのはじめの経路は以下のとおりでした。
- Client->R1->192.168.22.62->...->胡散臭いサーバ
- R1->192.168.22.62->...->胡散臭いサーバ
- R2->R1->192.168.22.62->...->胡散臭いサーバ
どれも192.168.22.62/30を通るが、そこでよくパケットが落ちるので、192.168.22.54/30経由で胡散臭いASに接続します。
そこで、static routeをR1, R2に設定し、経路を以下のように変更します。
- Client->R1->R2->192.168.22.54->...->胡散臭いサーバ
- R1->R2->192.168.22.54->...->胡散臭いサーバ
- R2->192.168.22.54->...->胡散臭いサーバ




clientから`192.168.22.54` にpingを飛ばすと，行きは必ず下の専用線で行くが，帰りは上の専用線経由で echo replyが返ってくる
しかも不安定

## いつの間にか復活している君 (50) masao

回答:

```
お世話になっております．チームelabです．

この問題では Docker Engine のサービスの自動起動が無効化されていることが原因でトラブルが発生したと考えられます．
そのため，以下のように設定を変更し，再起動後に自動で Docker 上で動く nginx が正常に起動することを確認しました．
確認のほどよろしくお願いいたします．

## 手順

### 1. docker.service を enable する

`sudo systemctl enable docker` により `docker.service` の自動起動を有効化．

### 2. 再起動して確認

`sudo reboot` より再起動後，しばらくして自動で踏み台から `curl -I 192.168.17.1` してレスポンスコードが正常であることを確認．

```

## Webサーバーに繋がらない！ (50) hyuga
```
お世話になっております。elabです。

この問題では

apparmorの設定
ゾーンファイルの問題
ことが原因でトラブルが発生したと考えられました。
そのため、以下のように設定を変更し、DNSが正しく動くことを確認いたしました。
確認のほどよろしくお願いします。

apparmorの設定変更
ログを確認すると /etc/bind/managed-keys.bind.jnl の作成に，permission denied のエラーで失敗していることがわかります．

/etc/bind のパーミッションを確認すると，bindユーザに書き込み権限を持っているため単純なパーミッションのエラーでないことがわかります．

そこでapparmarの設定を疑います．
現在の設定を確認すると，named に関して設定されていることがわかります．

$ apparmor_status
...
3 processes are in enforce mode.
   /usr/sbin/chronyd (488) 
   /usr/sbin/chronyd (490) 
   /usr/sbin/named (750) 
...
設定ファイル /etc/apparmor.d/usr.sbin.named を確認すると，/etc/bind/* は読み取り権限のみが設定されており，書き込み権限は設定されていないことがわかります．

したがって，/etc/apparmor.d/usr.sbin.named を編集して書き込み権限を追加します．

-  /etc/bind/** r,
+ /etc/bind/** rw,
変更を適用します．

# apparmor_parser -r /etc/apparmor.d/usr.sbin.named
namedを再起動して，エラーが起きていないことを確認します．

# systemctl restart named
ゾーンファイルの編集
NSレコードの修正
NSレコードの名前の指定において末尾のピリオドが存在しないので /etc/bind/ex.zone を以下のように修正します．

-         IN  NS  ns.example.com
+        IN  NS  ns.example.com.
wwwレコードの追加
webレコードは存在していますが，wwwレコードが存在していないので追加します．

/etc/bind/ex.zoneに以下の行を追加します．

+ www     IN  A   192.168.8.1
変更を適用します

# rndc reload
確認
digコマンドで「www.example.com」「ns.example.com」が名前解決できる。
DNSサーバから確認
root@jnn-dns:/etc/bind# dig www.example.com +short
192.168.8.1
root@jnn-dns:/etc/bind# dig ns.example.com +short
192.168.8.2
Webサーバから確認
user@jnn-web:~$ dig www.example.com +short
192.168.8.1
user@jnn-web:~$ dig ns.example.com +short
192.168.8.2
systemctlコマンドでbindが正常に起動でき、systemctlコマンドのstatusオプションを用いて正常に起動していることを確認できる。
root@jnn-dns:/etc/bind# systemctl status named
● named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2021-03-07 12:21:35 JST; 21min ago
       Docs: man:named(8)
   Main PID: 750 (named)
      Tasks: 5 (limit: 1168)
     Memory: 15.3M
     CGroup: /system.slice/named.service
             └─750 /usr/sbin/named -f -u bind -4

Mar 07 12:40:44 jnn-dns named[750]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Mar 07 12:40:44 jnn-dns named[750]: automatic empty zone: EMPTY.AS112.ARPA
Mar 07 12:40:44 jnn-dns named[750]: automatic empty zone: HOME.ARPA
Mar 07 12:40:44 jnn-dns named[750]: none:100: 'max-cache-size 90%' - setting to 883MB (out of 981MB)
Mar 07 12:40:44 jnn-dns named[750]: configuring command channel from '/etc/bind/rndc.key'
Mar 07 12:40:44 jnn-dns named[750]: reloading configuration succeeded
Mar 07 12:40:44 jnn-dns named[750]: reloading zones succeeded
Mar 07 12:40:44 jnn-dns named[750]: all zones loaded
Mar 07 12:40:44 jnn-dns named[750]: running
Mar 07 12:40:44 jnn-dns named[750]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
エラーメッセージがなくなっていることが確認できます．

システム再起動時にbindが自動的に立ち上がる。
再起動後に systemctl status named が正常であることを確認しました．

以上よろしくお願いいたします．
```

## Server Sent Eventsが動作しない‼ (50) masao

回答:

```
お世話になっております．チームelabです．

この問題では `/etc/nginx/nginx.conf` におけるリバースプロキシの設定で `proxy_buffering` が `on` になっていたことが原因でトラブルが発生したと考えられます．
そのため，以下のように設定を変更し，正しくリバースプロキシ上で SSE が動作することを確認しました．
確認のほどよろしくお願いいたします．

## 手順

### 1. `/etc/nginx/nginx.conf` の `proxy_buffering` の設定を変更

`proxy_buffering on;` から `proxy_buffering off;` へ変更

### 2. nginx の再起動

`sudo systemctl restart nginx` により nginx を再起動

```


## このOpenstackなんか変だよぉ…(100) shin

- ~~クソ問題か…？~~
- configファイル内にUnicode文字が（コメントであっても）含まれるとコンフィグパーサでエラーが出る…？
- 日本語消せ

### 回答

お世話になっております。elabです。

この問題では`cinder.conf`にUnicode文字が含まれていることが原因でトラブルが発生したと考えられました。
そのため、以下のように設定ファイルを変更し、Cinder volumeコマンドが正しく動くことを確認いたしました。
確認のほどよろしくお願いします。


#### 手順

##### 0. エラーの確認

```bash
root@vm1 user(keystone)# openstack volume list

Internal Server Error (HTTP 500)
```

このとき`/var/log/apache2/cinder_error.log`にコンフィグ変換時のASCIIコードに関するエラーが発生している

```
tail -f /var/log/apache2/cinder_error.log

2021-03-07 13:23:19.610890     return self._parse_config_files()
2021-03-07 13:23:19.610901   File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 2919, in _parse_config_files
2021-03-07 13:23:19.610907     ConfigParser._parse_file(config_file, namespace)
2021-03-07 13:23:19.610918   File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 1604, in _parse_file
2021-03-07 13:23:19.610924     parser.parse()
2021-03-07 13:23:19.610934   File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 1559, in parse
2021-03-07 13:23:19.610940     return super(ConfigParser, self).parse(f.readlines())
2021-03-07 13:23:19.610951   File "/usr/lib/python3.8/encodings/ascii.py", line 26, in decode
2021-03-07 13:23:19.610956     return codecs.ascii_decode(input, self.errors)[0]
2021-03-07 13:23:19.610983 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe8 in position 12: ordinal not in range(128)
```

##### 1. `/etc/cinder/cinder.conf`の編集

- コンフィグファイルからUnicode文字（日本語）を削除する

```/etc/cinder/cinder.conf
[DEFAULT]
#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# Set host ip-addr
my_ip = 192.168.9.1
rootwrap_config = /etc/cinder/rootwrap.conf
api_paste_confg = /etc/cinder/api-paste.ini
state_path = /var/lib/cinder
auth_strategy = keystone
#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# Set RabbitMQ info
transport_url = rabbit://openstack:password@192.168.9.1
enable_v3_api = True
#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# Set Glance server
glance_api_servers = http://192.168.9.1:9292
#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# This value can be empty
enabled_backends = lvm

#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# Set MariaDB info
[database]
connection = mysql+pymysql://cinder:password@192.168.9.1/cinder

#----------------------------------------
# Change: change comment
# team: elab
#----------------------------------------
# Set Keystone auth info
[keystone_authtoken]
www_authenticate_uri = http://192.168.9.1:5000
auth_url = http://192.168.9.1:5000
memcached_servers = 192.168.9.1:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = cinder
password = servicepassword

[oslo_concurrency]
lock_path = $state_path/tmp

[lvm]
target_helper = tgtadm
target_protocol = iscsi
target_ip_address = 192.168.9.1
volume_group = cinder-volumes
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volumes_dir = $state_path/volumes
```

##### 2. 動作確認

```bash
openstack volume list

# (なにも表示されない)
```

```bash
openstack volume service list

+------------------+---------+------+---------+-------+----------------------------+
| Binary           | Host    | Zone | Status  | State | Updated At                 |
+------------------+---------+------+---------+-------+----------------------------+
| cinder-scheduler | vm1     | nova | enabled | up    | 2021-03-07T04:45:25.000000 |
| cinder-volume    | vm1@lvm | nova | enabled | up    | 2021-03-07T04:45:26.000000 |
+------------------+---------+------+---------+-------+----------------------------+
```



## ???

## DNSサーバを作りたかったらしい (50) hyuga
```
お世話になっております。elabです。

この問題ではslaveのゾーンファイルの場所が重複していることが原因でトラブルが発生したと考えられました。
そのため、以下のように設定を変更し、slaveのDNS serverが正しく動くことを確認いたしました。
確認のほどよろしくお願いします。

## ゾーンファイルの場所の重複

### 問題の確認方法
以下のコマンドで設定ファイルを検証します

root@ns02:/etc/bind# named-checkconf named.conf
/etc/bind/named.conf.prob:72: writeable file '/var/lib/bind/prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:36
/etc/bind/named.conf.prob:81: writeable file '/var/lib/bind/alice.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:43
/etc/bind/named.conf.prob:87: writeable file '/var/lib/bind/text.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:48
/etc/bind/named.conf.prob:93: writeable file '/var/lib/bind/tower.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:53
/etc/bind/named.conf.prob:99: writeable file '/var/lib/bind/home.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:58
/etc/bind/named.conf.prob:105: writeable file '/var/lib/bind/study.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:63
view "internal" と view "external" でゾーンファイルの場所が重複していることがわかるので，以下のように修正します．
修正方法
named.conf の修正
/etc/bind/named.conf.probを以下のように編集します．以下はdiffになります．

diff --git a/named.conf.prob b/named.conf.prob
index d192fd2..0b36610 100644
--- a/named.conf.prob
+++ b/named.conf.prob
@ -27,40 +27,40 @@ view "internal" {
     recursion yes;
     zone "18.168.192.in-addr.arpa" {
         type slave;
         file "/var/lib/bind/18.168.192.in-addr.arpa";
         file "/var/lib/bind/internal/18.168.192.in-addr.arpa";
         masters { 192.168.18.1; };
         allow-query { any; };
     };
     zone "prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/prob.final.ictsc.net";
+        file "/var/lib/bind/internal/prob.final.ictsc.net";
         masters { 192.168.18.1; };
         allow-query { any; };
         allow-notify { 192.168.18.1; };
     };
     zone "alice.prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/galice.prob.final.ictsc.net";
+        file "/var/lib/bind/internal/alice.prob.final.ictsc.net";
         masters { 192.168.18.1; };
     };
     zone "text.prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/gtext.prob.final.ictsc.net";
+        file "/var/lib/bind/internal/text.prob.final.ictsc.net";
         masters { 192.168.18.1; };
     };
     zone "tower.prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/gtower.prob.final.ictsc.net";
+        file "/var/lib/bind/internal/tower.prob.final.ictsc.net";
         masters { 192.168.18.1; };
     };
     zone "home.prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/ghome.prob.final.ictsc.net";
+        file "/var/lib/bind/internal/home.prob.final.ictsc.net";
         masters { 192.168.18.1; };
     };
     zone "study.prob.final.ictsc.net" in {
         type slave;
-        file "/var/lib/bind/gstudy.prob.final.ictsc.net";
+        file "/var/lib/bind/internal/study.prob.final.ictsc.net";
         masters { 192.168.18.1; };
     };
 };
bindの起動
以下のコマンドでbindを起動します．

/etc/init.d/bind9 start
確認
digコマンドにより正しく名前解決ができるようになっていることを確認します．

root@ns02:/etc/bind# dig @localhost red.prob.final.ictsc.net

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @localhost red.prob.final.ictsc.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26453
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 82816ab07daed6535249e2196044369901eb6fb236e81b45 (good)
;; QUESTION SECTION:
;red.prob.final.ictsc.net.      IN      A

;; ANSWER SECTION:
red.prob.final.ictsc.net. 300   IN      A       192.168.18.1

;; AUTHORITY SECTION:
prob.final.ictsc.net.   300     IN      NS      blue.prob.final.ictsc.net.
prob.final.ictsc.net.   300     IN      NS      red.prob.final.ictsc.net.

;; ADDITIONAL SECTION:
blue.prob.final.ictsc.net. 300  IN      A       192.168.18.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 07 02:12:41 UTC 2021
;; MSG SIZE  rcvd: 146
以上よろしくお願いいたします．
```

## インターネット壊れた (50) hyuga

R1-R2間の疎通がないので、BGPでの経路交換が出来ないのが問題
static routeを設定すれば簡単にできるが、動的経路制御を使えとのこと
OSPFでうまくR1-R2で経路交換する

## docker-mailman (50) (hide)

お世話になっております。elabです。
まず、dockerコマンドがuserから使えなかったので、dockerグループにuserを追加します。
dockerグループが存在しない場合は作成しますが、本環境では既に存在したので、作成せずにグループに追加します。そしてnewgrpコマンドでグループの設定をuserに適用します。
```
sudo usermod -aG docker $USER
newgrp docker
```
次に、コンフィグを置くディレクトリを作ります。
```
mkdir -p /opt/mailman/core
mkdir -p /opt/mailman/web
```
次に、mailman-webの8000/tcpポートを公開するための設定とSECRET_KEY・UWSGI_STATIC_MAPの設定を加えます。
```
user@docker-mailman-vm:~/docker-mailman$ cat docker-compose.yaml 
version: '2'

services:
  mailman-core:
    image: maxking/mailman-core:0.3
    container_name: mailman-core
    hostname: mailman-core
    volumes:
    - /opt/mailman/core:/opt/mailman/
    stop_grace_period: 30s
    links:
    - database:database
    depends_on:
    - database
    environment:
    - DATABASE_URL=postgres://mailman:mailmanpass@database/mailmandb
    - DATABASE_TYPE=postgres
    - DATABASE_CLASS=mailman.database.postgresql.PostgreSQLDatabase
    - HYPERKITTY_API_KEY=lCTSC2020
    networks:
      mailman:
        ipv4_address: 172.19.199.2

  mailman-web:
    image: maxking/mailman-web:0.3
    container_name: mailman-web
    hostname: mailman-web
    depends_on:
    - database
    links:
    - mailman-core:mailman-core
    - database:database
    volumes:
    - /opt/mailman/web:/opt/mailman-web-data
    environment:
    - DATABASE_TYPE=postgres
    - DATABASE_URL=postgres://mailman:mailmanpass@database/mailmandb
    - HYPERKITTY_API_KEY=ICTSC2020
    - SECRET_KEY=ICTSC2020
    - UWSGI_STATIC_MAP=/static=/opt/mailman-web-data/static
    ports:
    - 8000:8000
    networks:
      mailman:
        ipv4_address: 172.19.199.3

  database:
    environment:
      POSTGRES_DB: mailmandb
      POSTGRES_USER: mailman
      POSTGRES_PASSWORD: mailmanpass
    image: postgres:9.6-alpine
    volumes:
    - /opt/mailman/database:/var/lib/postgresql/data
    networks:
      mailman:
        ipv4_address: 172.19.199.4

networks:
   mailman:
     driver: bridge
     ipam:
       driver: default
       config:
       -
         subnet: 172.19.199.0/24
```
最後にdocker-composeで起動します。

docker-compose up

手元のPCからダイナミックフォワードした上で、ブラウザからSOCKSプロキシを利用してhttp://172.19.199.3:8000にアクセスすると、webページが見れます。


## リバースプロキシが動かない (50) masao

実環境のドメイン名 `gwn.2020-final.ictsc.net`

原因1: `ssl-default-bind-ciphers` に謎の改行
原因2: mozilla SSL Configuration Generator の HAProxy のバージョンがおかしい (`ssl-default-bind-ciphersuites` はない)
原因3: haproxy に与える証明書に秘密鍵が含まれていない
原因4: haproxy に与える証明書にCA証明書が含まれていない `cat server.pem chain.pem server.key > haproxy.pem`
原因5: `acl is_gwn_local hdr_end(host) -i ictsc.net` に変更


```
お世話になっております．チームelabです．

この問題では以下の原因でプロキシが正常に動作していませんでした．
そのため，以下のように設定を変更し，設定変更後踏み台サーバから正しくことを確認しました．
確認のほどよろしくお願いいたします．

## 原因と修正

### 1. `ssl-default-bind-ciphers` に謎の改行がある

`ssl-default-bind-ciphers` の文中に謎の改行があったため取り除きました．

### 2. mozilla SSL Configuration Generator の HAProxy のバージョンがおかしい

TLS関連の設定を生成する mozilla SSL Configuration Generator に与える HAProxy のバージョンに誤りが合ったため，正しいバージョン (1.8.8) を与えて生成し直しました．
該当バージョンに `ssl-default-bind-ciphersuites` はなかったため削除しました．

### 3. HAProxy に与える証明書に秘密鍵・CA証明書が含まれていない

HAProxy に与える証明書に秘密鍵・CA証明書が含まれていなかったため含めるようにしました．
また，HAProxy に与える証明書ファイルの所有者とグループを `haproxy` としました．

### 4. `frontend` セクションの `acl` に誤りがある

HAProxy の設定の `frontend` セクションに誤りがあったため，`acl is_gwn_local hdr_end(host) -i ictsc.net` に変更しました．

### 5. 踏み台からの疎通確認

`curl https://gwn.2020-final.ictsc.net` によりページが表示されることを確認しました．

```


## なぜか動きません！ (50) masao

解答

```
お世話になっております．チームelabです．

この問題では `docker-compose.yml` 及び `Dockerfile` で指定されたイメージのアーキテクチャが誤っていたこと，及び`Dockerfile` 内に全角スペースが入っていたこと，また MariaDB にて接続用パスワード/パスワードレスの設定が行われていなかったことが原因でトラブルが発生したと考えられます．
そのため，以下のように設定を変更し，再起動後に自動で docker-compose で定義された nginx 及び MariaDB が正常に起動することを確認しました．
確認のほどよろしくお願いいたします．

## 手順

### 1. `Dockerfile` 内の全角スペースを削除

`FROM` ディレクティブの隣に全角スペースがあったため，削除して半角スペースにした．

### 2. `Dockerfile` 及び `docker-compose.yml` 内のイメージを正しいアーキテクチャのものに修正

`Dockerfile` 及び `docker-compose.yml` で指定されていたイメージのアーキテクチャが誤っていたため，`x86_64 (amd64)` のものに変更した．

### 3. MariaDB にパスワードレス接続を許可する設定を追加

`docker-compose.yml` の `environment` に `MYSQL_ALLOW_EMPTY_PASSWORD=yes` を追加

### (4. `docker-compose.yml` に `ports` を追加)

念のため疎通を確認するためにローカルマシンの `127.0.0.1` へのポートバインドを追加．

```

## 証明書の取得が出来ない!! (100) hide

## Nginxが展開できない (50)  ☓~~akky~~

#### 怪しい点
- kubernetesで永続ストレージの確保が上手くいっていない
- 

```
user@kzz-k8s-master:~$ kubectl get po
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-64c5ffb9fd-666ct   0/1     Pending   0          6d16h
nginx-deployment-64c5ffb9fd-vgsdz   0/1     Pending   0          6d16h
nginx-deployment-64c5ffb9fd-wfcqf   0/1     Pending   0          6d16h

user@kzz-k8s-master:~$ kubectl get svc
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1       <none>           443/TCP        6d18h
nginx        LoadBalancer   10.104.33.237   192.168.12.100   80:31343/TCP   6d16h
```
```
user@kzz-k8s-master:~$ kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     3            0           6d16h

kubectl describe pod nginx-deployment-64c5ffb9fd-666ct
Name:           nginx-deployment-64c5ffb9fd-666ct
Namespace:      default
Priority:       0
Node:           <none>
Labels:         app=nginx
                pod-template-hash=64c5ffb9fd
Annotations:    <none>
Status:         Pending
IP:             
IPs:            <none>
Controlled By:  ReplicaSet/nginx-deployment-64c5ffb9fd
Containers:
  nginx:
    Image:        nginx:1.7.9
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:
      /usr/share/nginx/html from nginx-data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-8jgmm (ro)
Conditions:
  Type           Status
  PodScheduled   False 
Volumes:
  nginx-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  cephfs-pvc
    ReadOnly:   false
  default-token-8jgmm:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-8jgmm
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason            Age                    From               Message
  ----     ------            ----                   ----               -------
  Warning  FailedScheduling  3m43s (x559 over 11h)  default-scheduler  0/4 nodes are available: 4 pod has unbound immediate PersistentVolumeClaims.
```

```
$ kubectl get pvc
NAME         STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cephfs-pvc   Pending                                      csi-cephfs     6d16h

$ 
kubectl describe pvc cephfs-pvc
Name:          cephfs-pvc
Namespace:     default
StorageClass:  csi-cephfs
Status:        Pending
Volume:        
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-provisioner: rook-ceph.cephfs.csi.ceph.com
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Used By:       nginx-deployment-64c5ffb9fd-666ct
               nginx-deployment-64c5ffb9fd-vgsdz
               nginx-deployment-64c5ffb9fd-wfcqf
Events:
  Type    Reason                Age                     From                                                                                                             Message
  ----    ------                ----                    ----                                                                                                             -------
  Normal  ExternalProvisioning  3m23s (x2741 over 11h)  persistentvolume-controller                                                                                      waiting for a volume to be created, either by external provisioner "rook-ceph.cephfs.csi.ceph.com" or manually created by system administrator
  Normal  Provisioning          1s (x146 over 11h)      rook-ceph.cephfs.csi.ceph.com_csi-cephfsplugin-provisioner-558b4777b-bbk6z_2090b12f-f41f-482f-bf01-250f5f93ac72  External provisioner is provisioning volume for claim "default/cephfs-pvc"
```


# 1日目
## ボク わるいフレームワークじゃないよ(50) hyuga
https://deep-blog.jp/engineer/4287/

```
お世話になっております。elabです。

この問題ではDjangoのallowed hostsが原因でトラブルが発生したと考えられました。
そのため、以下のように設定を変更し、正しく動くことを確認いたしました。
確認のほどよろしくお願いします。

# ALLOWED_HOST の追加
Djangoの設定ファイルである `/home/user/ictsc/ictsc/settings.py` を以下のように編集し，`192.168.7.2` からの通信を許可します

-ALLOWED_HOSTS = []
+ALLOWED_HOSTS = ['192.168.7.2']

保存すると自動で再読込が行われ，設定が反映されます． 

# 確認
以下のコマンドで確認を行います．

user@vm:~/ictsc/ictsc$ curl http://192.168.7.2:8000/message/

以下のメッセージが得られます．                
Excellent!! If you're able to see this, report back now!!

```


## あれ、、、おかしい(100)

## とんとんとんねる(100) ~~akky~~

<!-- 
`gNodeB`から`192.168.21.50`にpingを飛ばすと，`gtptun@gNodeB`からecho request が飛んでいるっぽい
確かに，`gNodeB`のrouteを見ると`192.168.21.48/28`はgtptunを通るように設定されている

ということは相手側とトンネリングが繋がっていなさそう？

`gNodeB`から`192.168.21.`


| ping from | gNodeB | UPF  | DN |
| -------- | -------- | -------- | ---- |
|192.168.21.33| o| o | x |
|192.168.21.34| o| o | x |
|192.168.21.49| x| o | o |
|192.168.21.50| x| o | o |

まあそれはそう
UPFのiptablesには何も書かれていない -->
`~/gtp5g`, `~/libgtp5gnl`に書いてあるが，これを見るのか...？

https://github.com/PrinzOwO/libgtp5gnl

```
$ sudo ./tools/gtp5g-tunnel list pdr
[PDR No.1 Info]
  - Precedence: 1
  - Outer Header Removal: 0
  [PDI Info]
    - UE IPv4: 10.0.0.1
    [Local F-Teid Info]
      - In Teid: 100
      - Local GTP-U IPv4: 192.168.21.33
  - FAR ID: 1
[PDR No.2 Info]
  - Precedence: 2
  [PDI Info]
    - UE IPv4: 10.0.0.1
  - FAR ID: 2
```
```
$ sudo ./tools/gtp5g-tunnel list far
[FAR No.2 Info]
  - Apply Action: 2
  [Forwarding Parameter Info]
    [Outer Header Creation Info]
      - Description: 0
      - Out Teid: 100
      - Next GTP-U IPv4: 192.168.21.34
      - Port: 2152
  - Related PDR ID: 2 (Not a real IE)

```

## 何かがおかしい。。。。(150) ~~hyuga~~

```
~/go/src/github.com/yoneyan/ictsc-ace/pkg/routing/router/router.go
```
のどこかを編集したらよさそう．
カーネルパラメータはいじっちゃだめとか言っているので，パケットのチェックサムあたりを疑ったがよくわからず．

パケット処理のライブラリは `gopacket` を使っているので，そのドキュメントを読めば何かわかるかも？
https://pkg.go.dev/github.com/google/gopacket@v1.1.19

編集したらビルドして再起動．
```
~/go/src/github.com/yoneyan/ictsc-ace/cmd/routing$ go build .
~/go/src/github.com/yoneyan/ictsc-ace/cmd/routing$ sudo ./routing start eth1 eth2 eth3 eth4
```

デバッグのために処理しているパケットのsrcIP -> dstIPをプリントするように編集している．


## 部署を統合したが…(150)

~~masao~~

SELinux の問題っぽい...

**現在の SELinux コンテキスト**
- staff (user): `staff_u:staff_r:staff_t:s0-s15:c100,c200`
- employee2 `user_u:user_r:user_t:s0-s2:c200`
- employee1 `user_u:user_r:user_t:s0-s1:c100`

`ls -Z`でSELinuxのファイルのセキュリティコンテクストを見たいが，多分全部解除した状態じゃないとpermission deniedされそう
一回解除してみたい
`setenforce 0` します

## まだだ，まだ終わらんよ(150) shin

- ~~これでいいのか…？~~
- `/dev/sdb`を修復しないとダメでした

### 回答 (Take 2)

お世話になっております。elabです。

この問題では昔のプロジェクトで使用していたディスク`/dev/sdb`のパーティションテーブルが損傷しており認識されていないため、
Webページデータにアクセスできない状態になっていると考えられました。
そのため、以下の手順でパーティションテーブルを修復し、Webサーバーが復旧されていることを確認いたしました。
確認のほどよろしくお願いします。


#### 手順

##### 0. （確認） エラーの確認

###### 403エラーの確認

```bash
curl -I 192.168.11.1

HTTP/1.1 403 Forbidden
...
```

```bash
sudo tail /var/log/nginx/error.log

...
2021/03/06 xx:xx:xx [error] xxx#xxx: *1 directory index of "/mnt/data/" is forbidden, client: 192.168.11.1, server: _, request: "GET / HTTP/1.1", host: "192.168.11.1"
```

- `/mnd/data`に関して403エラーが返ってきている

###### ディスクの確認

```bash
sudo cat /etc/fstab

...
/dev/sdb1 /mnt/data ext4 defaults 0 0
```

```bash
sudo lsblk

...
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0   16G  0 disk
sdc       8:32   0  368K  0 disk
```

- `/dev/sdb1`を`/mnt/data`にマウントしたいが、`/dev/sdb1`が認識されていない

##### 1. パーティションテーブルの修復

```bash
sudo gdisk /dev/sdb
```

```gdisk
GPT fdisk (gdisk) version 1.0.5

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): Y

Command (? for help): n
Partition number (1-128, default 1): [ENTER]
First sector (34-33554398, default = 2048) or {+-}size{KMGTP}: [ENTER]
Last sector (2048-33554398, default = 33554398) or {+-}size{KMGTP}: [ENTER]
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): [ENTER]
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.
```

- [ENTER]部分は何も入力せずにENTERキーを押下する

##### 2. ディスク復旧の確認

```bash
sudo lsblk

...
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0   16G  0 disk 
└─sdb1    8:17   0   16G  0 part /mnt/data
sdc       8:32   0  368K  0 disk
```

##### 3. マウントする

```bash
sudo mount -a
```

```bash
ls /mnt/data/

index.html  lost+found
```

##### 4. 復旧確認

```bash
curl 192.168.11.1
```

```index.html
<!DOCTYPE html>
<html lang="ja">
        <head>
                <meta charset="utf-8" />
                <link rel="stylesheet"  href="style.css">
                <title>タイトル</title>
                <script
                          src="https://code.jquery.com/jquery-3.3.1.min.js"
                            integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
                              crossorigin="anonymous"></script>
        </head>
        <body>
                <main>
                        <p>ICTSC WEB!!!</p>
                </main>
        <script>
                $(function(){
                });
        </script>
        </body>
</html>
```

### 回答 (Take 1)

お世話になっております。elabです。

この問題では昔のプロジェクトで使用していたディレクトリ配下に一切のデータが存在せず、
indexページファイルが存在しないためアクセスできない状態になっていると考えられました。
そのため、エラーページを表示させないためには、少なくとも以下の2つの方法が考えられます。
確認のほどよろしくお願いします。


#### 手順

##### 0. （確認） エラーの確認

```bash
curl -I 192.168.11.1

HTTP/1.1 403 Forbidden
...
```

```bash
sudo tail /var/log/nginx/error.log

...
2021/03/06 xx:xx:xx [error] xxx#xxx: *1 directory index of "/mnt/data/" is forbidden, client: 192.168.11.1, server: _, request: "GET / HTTP/1.1", host: "192.168.11.1"
```

```bash
ll /mnt/data
```

- `/mnd/data`に関して403エラーが返ってきている
- `/mnt/data`上に一切のデータが存在しない

##### 1. エラーページを表示させないための設定

###### （方法1）indexページが存在しないディレクトリではディレクトリ下のファイル一覧を表示させるようにする

- Nginxの設定ファイル(`/etc/nginx/sites-enabled/ictsc`)を書き換える

```/etc/nginx/sites-enabled/ictsc
# ...
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # ...

        # 以下を追加
        autoindex on;
        autoindex_exact_size off;
        autoindex_localtime on;

        # ...
```

- Nginxリロード

```bash
sudo nginx -s reload
```

###### （方法2）適当なindexページを`/mnt/data/`下に作成する

- 新規作成してもよいが、すでに存在しているデフォルトファイルのどちらかを利用してもよい
    - `/var/www/html/index.nginx-debian.html`
    - `/usr/share/nginx/html/index.html`

```bash
sudo ln -s /usr/share/nginx/html/index.html /mnt/data/index.html
```

##### 2. ステータス確認

```bash
curl -I 192.168.11.1

HTTP/1.1 200 OK
...
```



## FTPが壊れちゃった！(50) hide
user/ictsc2020でログイン

お世話になっております。elabです。

`/etc/vsftpd.conf`を参照すると以下の設定がありましたが、`/etc/vsftpd.chroot_list`というファイルが存在しなかったので、作成しました。
```
chroot_list_file=/etc/vsftpd.chroot_list
```
`/etc/vsftpd.chroot_list`を以下の内容で作成しました。
```
user
```
これによってFTPサーバーにログインできるようになりました。
```
user@vm1:~$ lftp -u user 192.168.3.1
Password: 
lftp user@192.168.3.1:~> pwd                    
ftp://user@192.168.3.1
lftp user@192.168.3.1:~> exit
```


## GREが繋がらない!(100) hide (hyuga)
encaplimitの問題

トンネルインタフェースのencaplimit=noneにする必要があるが，vyosではnoneにできないのでipコマンドでトンネルインタフェースを作った


## 名前解決ができない？(100) ~~akky~~

<!-- まず ssh 192.168.2.128.131/25のキャッシュサーバ兼クライアントにSSHが繋がらない

権威サーバからルータに対してpingが通るが，権威サーバからキャッシュサーバ兼クライアントに対してpingが通らない

権威サーバ
```
default via 192.168.2.126 dev eth0 proto static metric 100
192.168.2.0/25 dev eth0 proto kernel scope link src 192.168.2.20 metric 100
```


| ping from | ルータ | 権威サーバ  | キャッシュサーバ |
| -------- | -------- | -------- | ---- |
| ルータ     | o    |  o     | o |
|権威サーバ | o | o  | o |
|キャッシュサーバ| o| x | o |

権威サーバのデフォルトゲートウェイが `192.168.2.126`になっているので，そちら側に向いていそう

これってどうするんだ...？ -->

`dig @192.168.2.131 pc1.ictsc.net`をクライアントから実行すると名前解決できない
`/var/named/data/run.log`

- `named(BIND)`で動作している
- `named-chroot`

[KSKロールオーバーについて \- JPNIC](https://www.nic.ad.jp/ja/dns/ksk-rollover/)
「3.1. キャッシュサーバの運用者、ネットワーク運用者」で，DNSSEC利用者

`named-chroot.service`が起動している

[Internet Week 2015 T5 今日から始めるDNSSECバリデーション \- JPNIC](https://www.nic.ad.jp/ja/materials/iw/2015/proceedings/t5/)が一番分かりやすい資料な気がする

#### debug方法

- `/var/named/data/named.run`を見る
- `/etc/named.conf`を書き換える
- `systemctl restart named-chroot.service`
- `rdnc reload`(コマンド違うかも)
- `dig @192.168.2.131 pc1.ictsc.net`

### 回答

```
お世話になっております。elabです。

この問題ではキャッシュサーバにおいて，
validating ictsc.net/DNSKEY: verify failed due to bad signature (keyid=63829): RRSIG has expired
validating ictsc.net/DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for 'ictsc.net'

というログが存在していました．
そのため，
`.root.key`
`dig @192.168.2.20 ictsc.net DNSSEC` に依って返ってくる値を用いてトラストアンカーの鍵を登録して再起動したところ，正しく問い合わせが行えるようになるようでした．
確認のほどよろしくお願いします。
```



## FTPなんも分からん(50) masao
回答者: masao

とりあえず中に入ってFTP接続してみるとLISTが失敗している? -> active mode を用いることで解決
しかしアップロードできない -> vsftp の write_enable=YES にすることで解決


```
お世話になっております．チームelabです．

この問題ではNAT状況下で特定のポートのみがFTPサーバにフォワードされている状況で，FTPのパッシブモードを用いて転送を行おうとしていることが原因であることが判明しました．
そのため，以下の手順でFileZillaの設定を変更し，正しく該当FTPサーバに接続できることを確認しました．

## 手順

### 1. FileZilla の設定において，優先的にアクティブモードを使用する

Edit->Settings から開かれる設定画面において，"Connection -> FTP" タブにおける "Transfer Mode" を Active に変更．

### 2. FileZilla の保存された接続に，該当FTPサーバを追加

GUI画面左上にある "Site Manager (アイコン)" ボタンを押して開かれる Site Manager において，今回接続対象となるFTPサーバを保存済み接続として追加．
(ISCTC FTP という接続名で保存されております．)

また，この問題ではパーミッションが適切であるにもかかわらず，ファイルをクライアントから一切アップロードできないという事象も発生しておりました．
そのため，以下の手順でFTPサーバの設定を変更し，ファイルアップロード機能を有効化しました．
ただし，有効化しても接続ユーザに編集権限のないディレクトリやファイルは編集不能です（例: 他人のhomeディレクトリなど）

### 3. /etc/vsftp.conf の変更

`/etc/vsftp.conf` を編集し， `write_enable=YES` に変更．


### 4. vsftpd の再起動

以下のコマンドにより，`vsftpd` を再起動．

`sudo systemctl restart vsftpd`

以上2件の対応より，クライアントから FileZilla を用いて該当FTPサーバにファイルアップロード及びダウンロードが可能となったことを確認しました．

```



## コンテナに繋がらない(50) shin (hyuga)
回答者：shin (hyuga)

- 自分で`docker network`を作成しているものの、未完成っぽい
- `docker network ls`ででてくる`40c3b553b46a   none      null      local`が問題のネットワーク


### 回答

お世話になっております。elabです。

この問題ではNginxコンテナに正しいdockerネットワークに接続されていないことが原因でトラブルが発生したと考えられました。
そのため、以下のように設定を変更し、疎通が取れることを確認いたしました。
確認のほどよろしくお願いします。


#### 手順

##### 0. （確認） Nginxコンテナのネットワークを確認する

```bash
docker inspect nginx
```

- `NetworkSettings->Networks` 下が `"none"` になっている

##### 1. Dockerネットワーク一覧を確認する

```bash
docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
xxxxxxxxxxxx   bridge    bridge    local
xxxxxxxxxxxx   host      host      local
xxxxxxxxxxxx   none      null      local
```

- `none`ネットワークではなく`bridge`ネットワークに接続し直せばよい

##### 2. 正しいDockerネットワークに接続し直す

```bash
docker network disconnect none nginx
docker network connect bridge nginx
```

##### 3. 疎通確認

```bash
curl 127.0.0.1:8080
```

```html
<!DOCTYPE html>
<html>
<head>
<title>Welcome to ICTSC2020!</title>
</head>
<body>
<h1>Welcome to ICTSC2020!</h1>
</body>
</html>
```


