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~~  `~/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~~  `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> ```