/
カテゴリー

概要

インカレ技術サークル ICTSC に入ったあなたは、Kubernetesクラスタチームに配属されました。
チームの先輩から、Kubernetes上にチーム紹介のWebサイトをつくるよう頼まれました。
Kubernetesのマニフェストは先輩に渡されたものから変更しないで欲しいそうです。
しかし、クラスタに適用したところ、Webサイト用のPodがPendingになってしまいます。
卒研の進捗が思わしくない先輩は教員の課題から手が離せないため、頑張ってあなたが解決してください。
解決後は、チーム名の書かれたWebサイトが見えるようにしておいてください。
問題が解決できればサークル内で共有したいため、原因と解決方法を報告してください。
先輩から渡され、k8sに適用したマニフェストは/home/user/manifestに保存されています。

前提条件

  • /home/user/manifestにあるファイルの内容を変更してはいけない

初期状態

  • NginxのDeploymentがPendingになっている。

終了状態

  • pendingとなっていたDeploymentが正常に稼働している。
  • 正常化したDeploymentによって稼働するNginxで、解答するチームの名前が書かれたWebサイトが確認できるようになっている。
  • 開始時と同じマニフェストのみが適用されている。

接続情報

VM名ホスト名
kzz-k8s-master192.168.12.1
kzz-k8s-node1192.168.12.2
kzz-k8s-node1192.168.12.3
kzz-k8s-node1192.168.12.4

解説

/home/user/manifestには、Flannel 、MetalLB、Rook、NginxのDeploymentが書かれたtest-nginx.yamlなどのマニフェストが保存されています。
test-nginx.yamlはPVC 、そのPVCを/usr/share/nginx/htmlにマウントするNginx のDeployment 及び、Nginx を公開するためのLoadBalancer Serviceを定義します。
問題環境では、問題名にあるNginx だけでなくPVC もPendingとなっています。
PendingになっているPVCをkubectl describe pvc cephfs-pvc で確認すると、failed to provision volume with StorageClassとエラーが出ています。

このKubernetesクラスタではRookを利用し、CephをPersistent Volumeとして使っています。
このことから、Rookの設定の異常等を予想し、Rookのエラーを確認する必要があります。
そのため、/home/user/manifestにあるRookのマニフェスト(cluster.yaml)では、無効化されているcrash-collectorを有効化し適用します。
立ち上がったcrash-collectorをkubectl describe で確認すると、Unable to attach or mount volumesとなっています。
Rookがマウントしてそうな場所を探すと、 cluster.yamlの33行目にdataDirHostPath: /var/lib/rookなる行があります。
そして、この直前の31行目のコメントに、

  # Important: if you reinstall the cluster, make sure you delete this directory from each host or else the mons will fail to start on the new cluster.

と書かれています。

原因としては、
Rookを削除する際にコンフィグ情報やログデータなどが保存されているdataDirHostPathを削除しなかったことです。
Rookを適用後、気まぐれに削除をした環境で、再度Rookを適用した場合に発生する現象です。
解決方法としては、RookのDocumentに書かれた通りにクラスターの清掃を行うだけです。
はじめに、適用されているRookを削除します。

kubectl delete -f filesystem.yaml 
kubectl delete -f storageclass.yaml
kubectl delete -f toolbox.yaml
kubectl delete -f cluster.yaml
kubectl delete -f operator.yaml
kubectl delete -f common.yaml

今回のマニフェストでdataDirHostPathはデフォルトの/var/lib/rookとなっています。
全てのKubernetes Nodeの/var/lib/rookを削除します。
最後に、Rookを適用すると正常に稼働することが確認できます。
ただし、本問題の条件としてマニフェストを変更しないことが挙げられているので、crash-collectorを無効にしておく必要があります。

kubectl apply -f common.yaml
kubectl apply -f operator.yaml
kubectl apply -f cluster.yaml
kubectl apply -f toolbox.yaml
kubectl apply -f storageclass.yaml
kubectl apply -f filesystem.yaml 

ただ、チーム名の書かれたWebサイトは用意されていないので、kubectl exec -it ”Pod名” -- bashをしてNginxのpodに入ります。
そのShellで、 echo -e "<a>”チーム名”</a>" > /usr/share/nginx/html/index.html を行えば終了です。

今回はrook1.2を利用していたので手動で削除しましたが、1.3から自動で消してくれるCleanup Policyなるものがあるらしいです。

採点基準

  • 原因(/var/lib/rookがRook作成時に残っていたので、前のクラスタの認証情報に邪魔されてクラスタが作成できない)が述べられている。 40%
  • 各ノードの/var/lib/rookを削除し、kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') ceph status にてHealthが HEALTH_OKになっている 20%
  • pvcが作成され、PVCを利用したNginxのPodが展開されている。 30%
  • 踏み台から各チーム名が記載されたWebサイトが確認できる。 10%

反省

採点基準を分けたものの、解決していないとどれも満たせないことに採点中気づきました。

 /
カテゴリー

問題文

概要

あなたが所属している会社で後輩が「FTPなんもわからん」と嘆いています。

NAT配下でのFTPサーバの検証をしているんですが、FileZillaからどうしても接続できないんです。先輩助けてください。

後輩を助けてあげてください。

前提条件

  • FileZillaがインストールされた後輩の検証環境にはVNCで接続できる
  • FTP ServerはRouterのNAT下におり、踏み台サーバからは直接アクセスできない
  • FTP ServerはRouterを踏み台にしてSSHできる
  • FileZillaで入力するFTPサーバのアクセス情報は下記の通り
HostUsernamePassword
192.168.10.1userictsc2020

初期状態

  • FileZillaでFTP ServerにFTP接続すると、下記のようにエラーが発生する
Error: The data connection could not be established: ENCONNREFUSED - Connection refused by server

終了状態

  • VNC Server上のFileZillaを用いて、FTP ServerにFTP接続し、ファイルのアップロード及びダウンロードが実行できる
  • 適切な問題の原因と解決法が回答に記載されている

トポロジ

トポロジ

解説

第1の問題

この問題はFTP ServerがPASVコマンドの応答として、0.0.0.0をクライアントに返答していたことが主な原因です。vsftpdがIPv6で動作する設定になっているとこのような現象が発生します。

この現象の解決方法として2通りあります。

1) vsftpdをIPv4のみで動作させる

/etc/vsftpd.conflisten=NOlisten=YESに、listen_ipv6=YESlisten_ipv6=NOに変更し、IPv4のみでvsftpdを再起動すると正しいパッシブアドレスを通知するようになります。

user@ftp:~$ diff -u /etc/vsftpd.conf{.org,}
--- /etc/vsftpd.conf.org    2021-03-07 12:14:47.218160952 +0900
+++ /etc/vsftpd.conf    2021-03-07 12:14:23.443283890 +0900
@@ -11,7 +11,7 @@
 #
 # Run standalone?  vsftpd can run either from an inetd or as a standalone
 # daemon started from an initscript.
-listen=NO
+listen=YES
 #
 # This directive enables listening on IPv6 sockets. By default, listening
 # on the IPv6 "any" address (::) will accept connections from both IPv6
@@ -19,7 +19,7 @@
 # sockets. If you want that (perhaps because you want to listen on specific
 # addresses) then you must run two copies of vsftpd with two configuration
 # files.
-listen_ipv6=YES
+listen_ipv6=NO
 #
 # Allow anonymous FTP? (Disabled by default).
 anonymous_enable=NO

2) FileZillaからアクティブモードで接続する

今回の構成では、FTP ServerからVNC Server(FTPクライアント)までは自由に接続ができる状態ですので、File Zillaの設定を変えてアクティブモードで接続することによっても解決可能です。

第2の問題

前述の方法でFTP接続を行っても、まだファイルのアップロードができません。これはvsftpd.confにおいて#write_enable=YESとコメントアウトされているためです。write_enable=YESに変更してファイルの書き込みを許可します。

最終的なvsftpd.confの差分は以下のようになります。

user@ftp:~$ diff -u /etc/vsftpd.conf{.org,}
--- /etc/vsftpd.conf.org    2021-03-07 12:22:25.287108937 +0900
+++ /etc/vsftpd.conf    2021-03-07 12:21:03.346616102 +0900
@@ -11,7 +11,7 @@
 #
 # Run standalone?  vsftpd can run either from an inetd or as a standalone
 # daemon started from an initscript.
-listen=NO
+listen=YES
 #
 # This directive enables listening on IPv6 sockets. By default, listening
 # on the IPv6 "any" address (::) will accept connections from both IPv6
@@ -19,7 +19,7 @@
 # sockets. If you want that (perhaps because you want to listen on specific
 # addresses) then you must run two copies of vsftpd with two configuration
 # files.
-listen_ipv6=YES
+listen_ipv6=NO
 #
 # Allow anonymous FTP? (Disabled by default).
 anonymous_enable=NO
@@ -28,7 +28,7 @@
 local_enable=YES
 #
 # Uncomment this to enable any form of FTP write command.
-#write_enable=YES
+write_enable=YES
 #
 # Default umask for local users is 077. You may wish to change this to 022,
 # if your users expect that (022 is used by most other ftpd's)

第1の問題を解決して満足したのか、終了条件のファイルのアップロード及びダウンロードが実行できるを確認しなかったチームが数チームありました。

パッシブアドレスについて(余談)

FTP Serverが通知しているパッシブアドレスはvsftpd.confで設定されているとおり、172.16.0.2です。本来であればFTP ServerのこのアドレスはNAT配下におり、この問題の構成ではVNC Server(FTPクライアント)から接続することはできません。

user@ftp:~$ tail /etc/vsftpd.conf
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO

#
# Uncomment this to indicate that vsftpd use a utf8 filesystem.
#utf8_filesystem=YES

pasv_min_port=1024
pasv_max_port=1124
pasv_address=172.16.0.2

ところが実際にパケットキャプチャを実施すると以下のようになります。

FTP Server -> Router(Routerの172.16.0.1のインタフェース)

30 7.559306 172.16.0.2 192.168.10.2 FTP 112 Response: 227 Entering Passive Mode (172,16,0,2,4,29).

Router -> VNC Server(Routerの192.168.10.1のインタフェース)

70 5.750541 192.168.10.1 192.168.10.2 FTP 114 Response: 227 Entering Passive Mode (192,168,10,1,4,84).

パケットキャプチャの結果からわかるように、Routerがパッシブモードで通知するアドレスの変換を実施しています。カーネルモジュールのnf_nat_ftpがロードされている場合こういった変換が行われるようです。

このモジュールをアンロードして再度パケットを見てみると下記のように変換が実施されないことがわかります。

user@router:~$ sudo rmmod nf_nat_ftp

Router -> VNC Server(Routerの192.168.10.1のインタフェース)

421 46.928655 192.168.10.1 192.168.10.2 FTP 112 Response: 227 Entering Passive Mode (172,16,0,2,4,20).

そのため今回の問題ではvsftpd.confのpasv_address=172.16.0.2を編集する必要はありませんが、実際の運用においてはハマりどころの一つなのでぜひ頭の片隅入れておいてください。

 /
カテゴリー

問題名

  • DNSサーバを作りたかったらしい

概要

あなたは同僚から助けを求められた。彼は社内のDNSサーバの構築ログに基づいて環境構築を試みたが、テストとして実行したコマンドでは期待していた出力が行われなかったらしい。原因を調査して、エラーを解決してあげよう。

前提条件

  • ns01はmaster、ns02はslaveサーバとして機能させたい
  • トラブルに関係しない要素については変更しない

初期状態

ns02でdig @localhost red.prob.final.ictsc.netが解決できない

終了状態

  • ns02でdig @localhost red.prob.final.ictsc.netが解決できる
  • 原因が特定されて報告される
    - トラブル解決前に期待されていた動作をしている

接続情報

VM名ホスト名ユーザパスワード
ns01192.168.18.1userictsc2020
ns02192.168.18.2userictsc2020

解説

この問題は、bindが設定ファイルのエラーによって起動していませんでした。

root@ns02: ~$ systemctl status  bind9
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2021-02-26 08:46:44 UTC; 1s ago
     Docs: man:named(8)
  Process: 1173 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
  Process: 1195 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE)
 Main PID: 1195 (code=exited, status=1/FAILURE)
Feb 26 08:46:44 ns02 named[1195]: /etc/bind/named.conf.prob:115: writeable file '/etc/bind/slave/alice.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:54
Feb 26 08:46:44 ns02 named[1195]: /etc/bind/named.conf.prob:120: writeable file '/etc/bind/slave/text.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:60
Feb 26 08:46:44 ns02 named[1195]: /etc/bind/named.conf.prob:125: writeable file '/etc/bind/slave/tower.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:66
Feb 26 08:46:44 ns02 named[1195]: /etc/bind/named.conf.prob:130: writeable file '/etc/bind/slave/home.prob.final.ictsc.net': already in use: /etc/bind/named.conf.prob:72
Feb 26 08:46:44 ns02 named[1195]: loading configuration: failure
Feb 26 08:46:44 ns02 named[1195]: exiting (due to fatal error)
Feb 26 08:46:44 ns02 systemd[1]: bind9.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 08:46:44 ns02 systemd[1]: bind9.service: Failed with result 'exit-code'.

解決方法は/etc/bind/named.conf.prob のエラー部でin-viewを用いることです。例えば以下のように表記します。

view external {
    match-clients { any; };

    zone example.com {
    in-view internal;
    };
};
  • 参考
    • https://bind9.readthedocs.io/en/latest/reference.html?highlight=in-view#multiple-views

bind9.11からこの表記法でエラーが出るようになったため、この問題は参考にしていたドキュメントが古いバージョンのものだったというシナリオでした。
CentOS7で現在提供されている最新バージョンなど、bind9.11.xによっては上記エラーを無視して起動できるようになっています。

採点基準

採点において、in-viewを用いずfileのパスを変更して重複を回避している例が多くありました。この問題は背景として、DNSサーバの構築練習途中であるという設定があり、基準内での解決であれば100%の採点がされています。また、この問題は社内DNSサーバの構築ログを参考にとあるようにある程度期待された動作があります。そのため、設定ファイルを大幅に変更することによるトラブル解決前に期待されていた動作をしているを満たしていない場合は減点がされます。

  • エラーを解決してBINDを起動し、指定のコマンドによる名前解決に成功する && 原因と解決方法について回答に記述されている(100%)
    • どちらかに不足があった場合は50%とする。

 /
カテゴリー

問題名

なぜか動きません!

概要

あなたは研修グループに所属にしているエンジニア兼先生です。
研修にて、サーバー上でDockerを用いてサービスを構築する研修課題を出題しました。
課題はDocker Compose を使って複数のイメージを起動してみる。という課題でした。ある一人の受講生がエラーが発生し、解決できないと相談しにきました。
エラーを解消し起動を行いなさい。

前提条件

サーバーのルール:Dockerイメージは公式イメージのみ
Docker Hubのサインインはしない

課題
次回,使用するためにWebサーバーとdbをdocker-compose.ymlとDockerfileを使って構築しましょう.
WebサーバーはNGINX,データベースはMariaDBを使用してください.

初期状態

  • /home/user/homework01に課題で使用したdocker-compose.ymlDockerfileが保存されている
  • $ docker-compose up -d に失敗する

終了状態

  • 課題の条件を達成する
  • $ docker-compose up -dが成功し、$ docker-compose psにて全てのコンテナのstatusupしている
  • 解答提出時にエラーが発生した原因を記述する

解説

初めて環境構築を行っていく上で間違えてしまう点、ARMとx86のアーキテクチャの違いと起動ログをみて原因を究明するということに焦点を当てて作成した問題になります。
まず、初期状態にて起動を行うと

$ docker-compose up
Starting homework01_db_1    ... done
Starting homework01_nginx_1 ... done
Attaching to homework01_nginx_1, homework01_db_1
db_1     | standard_init_linux.go:211: exec user process caused "exec format error"
nginx_1  | standard_init_linux.go:211: exec user process caused "exec format error"
homework01_db_1 exited with code 1
homework01_nginx_1 exited with code 1

と,起動に失敗します。

出題時のファイル

$ cat Dockerfile
FROM mariadb@sha256:eacab2a85f2692a71bbecec0ec1d4eab0a813409bc4760b2d15269b05aa2bafb
$ cat docker-compose.yml
version: '3'
services:
    nginx:
            image: nginx@sha256:8789e3c472689faa3849023e5272e887982f0714a9e3c89e4786b8cf614db2cf
    db:
            build: ./

第一関門

初めに、
全角スペースをDockerfileに混入されていることが原因で以下のエラーが出現します。

$ docker-compose build 
nginx uses an image, skipping
Building db
ERROR: Dockerfile parse error line 1: unknown instruction: FROM MARIADB@SHA256:EACAB2A85F2692A71BBECEC0EC1D4EAB0A813409BC4760B2D15269B05AA2BAFB

よってDockerfileの中にある全角を半角に置換します。

第二関門

docker のイメージ情報をみて使用イメージがVMで使用しているアーキテクチャのx86アーキテクチャCPU向けであることの確認します。

$ docker images 
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               <none>              2b71a68aa246        6 days ago          45.3MB
homework01_db       latest              d8d6819532a3        8 days ago          387MB
mariadb             <none>              d8d6819532a3        8 days ago          387MB
$ docker image inspect 2b71a6
.....
"Architecture": "arm",
.....

今回のVMはx86のアーキテクチャを使用してるので、ここの点を変更します。

第三関門

docker-conpsoe.ymlに環境設定の必要事項が未記入のため下記のエラーが出てMariaDBが起動していない。

db_1     | 2021-03-03 17:41:07+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
db_1     |     You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

docker-compose.ymlにて、必要事項を記入する

以上の3つの問題点を解決して起動をすると

$ docker-compose ps
       Name                     Command               State    Ports  
----------------------------------------------------------------------
homework01_db_1      docker-entrypoint.sh mysqld      Up      3306/tcp
homework01_nginx_1   /docker-entrypoint.sh ngin ...   Up      80/tcp  

無事に起動をすることができました。

正解例

$ cat Dockerfile
FROM mariadb@sha256:d866e756c68fce525419ee27e1d76a874c54072e49dfd591891acd28f95760fc
$ cat docker-compose.yml
version: '3'
services:
    nginx:
            image: nginx@sha256:3293470d994e1da29ba232de1809b4c88beb1f3c8352c0c171f8796038888493
    db:
            build: ./
            environment:
                    MYSQL_ROOT_PASSWORD: example

採点基準

以下の基準にて、問題環境と解答文の原因記載の両者ができて得点とする

  • 全角スペースの撤去(Dockefile内) 20%
  • Nginx/MariaDBのx86のイメージに変更(解答にてアーキテクチャの問題と明記している) 40%
  • MariaDBの必要設定を行う(解答分にて変更点を記載もしくはエラーの要因を記入) 40%
 /
カテゴリー

概要

reverse proxyとして、nginxを構築した。webページ自体は見れるが、sse(server sent events)はうまく動作しない。原因を糾明してsseが動作するようにしてほしい。

前提条件

初期状態

Reverse Proxy上で $ curl -N localhost/eventをしても応答がない。

終了状態

Reverse Proxy上で $ curl -N localhost/eventをしたら、

$ curl -N localhost/event

data: 1

data: 2

data: 3

...以下Ctrl+Cが入力されるまで続く

接続情報

VM名ホスト名ユーザパスワード
Reverse Proxy192.168.14.10userictsc2020

解説

この問題でServer Sent Eventsがうまく動作しなかった原因は、/etc/nginx/nginx.conf内のproxy_buffering on;だったことです。nginxのproxy_bufferingが有効な状態だとnginxがバッファリングしてしまい、クライアントがレスポンスを受け取れません。

想定解

/etc/nginx/nginx.conf内のproxy_buffering on;proxy_buffering off;に置き換えて、nginxを再起動させること

その他解法

nginxがデフォルトで使用するhttp/1.0はkeep-aliveを使用することは非推奨とされているので、
/etc/nginx/nginx.conf内のproxy_buffering on;proxy_http_version 1.1;に置き換えて、nginxを再起動させることでもServer Sent Eventsを動作させることができます。

採点基準

部分点は付けず、
Reverse Proxy上で $ curl -N localhost/eventをしたら、

$ curl -N localhost/event

data: 1

data: 2

data: 3

...以下Ctrl+Cが入力されるまで続く

と返ってくるような解答に満点をつけました。