ICTSC - HackMD

# ICTSC ## 踏み台 > ssh user@team17.bastion.ictsc.net -p 22 > CzcVsGfzWMJLdHxZ <a id="top"></a> | 問題 | 担当 | ポイント | | -------- | -------- | -------- | | [Jenkins が動かない！](#2) | 木村(done) | 50 | | [絵文字が入力できない！😭](#4) | hibi -> | 50 | | [BGPがEstablishedにならない](#3) | 林 -> | 50 | | [ファイルが送れない](#120) | 木村 | 50 | | [ログが転送できない！](#6) | hibi -> kimura | 50 | | [経路がおかしい](#6) | 室 | 50 | | [なんか通信できない(´・ω・｀)](#7) | 御手洗 | 50 | | [半径と直径](#8) | Text | 50 | | [hkk](#9) | 御手洗 Done | 11 | | [hka](#10) | 林 Done | 38 | | [hkn](#11) | 御手洗 Done | 15 | | [hkp](#12) | 林 Done | 21 | | [hki](#13) | 御手洗 Done | 20 | <a id="2"></a> 2. Jenkins が動かない！ [TOP](#top) ## 問題文概要 Kubernetes 上で Jenkins を動かしたかった A さんは、インターネット上の個人ブログに公開されているマニフェストファイルを利用して Jenkins を動作させようとしました。しかし、どうやらマニフェストファイルを適用してもブラウザから Jenkins のページが開けないどころか、 worker インスタンスが過負荷になってしまいました。ひとまず以下のように QoS を Pod に設定することで worker インスタンスが過負荷になる状況を避けることができましたが、依然 Jenkins はブラウザから確認できません。 limits: - cpu: 1 core - memory: 700 Mi - この問題を解決し、ブラウザから Jenkins のページを確認できるようにしてください。ネットワーク図 ``` +------------------+ +----------------+ | controlplane | | worker | | 192.168.255.41 |<----->| 192.168.255.42 | +------------------+ +----------------+ ``` 前提条件公式ドキュメントによると、Jenkins はメモリが 200MB あれば動作するようです。 https://www.jenkins.io/doc/book/scaling/hardware-recommendations/#memory-requirements-for-the-controller 初期状態ブラウザから Jenkins のページが開けず、connection refusedとなってしまう。接続方法は備考を参照問題環境に展開されている Jenkins のマニフェストファイルは、ホスト controlplane の /home/user/jenkins.yaml に配置されている。終了状態ブラウザから Jenkins のページを確認できる。備考以下の手順で、 SSH トンネル経由で Jenkins にアクセスできます踏み台サーバへのアクセス時にポートフォワーディングの設定をすることで、手元のブラウザから SSH 経由で Jenkins にアクセスできます以下は CLI から SSH する場合の例 ssh -L 31560:192.168.255.41:31560 <踏み台サーバにアクセスするためのユーザ>@<踏み台サーバのアドレス> ``` # 例. # ssh -L 31560:192.168.255.41:31560 user@<踏み台サーバのアドレス> 上記接続後、ブラウザから http://localhost:31560 にアクセスしてください ``` 問題環境 ``` $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy $ kubectl version Client Version: v1.28.2 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.28.2 ``` 回答内容確認 ## LOG kubectl describe jenkins-0でstatefulsetのjenkinsの確認 ``` Containers: jenkins: Container ID: containerd://1ff4f0d3a07321f2d2e7e8385400c0b33a51426377968823cb62c5ecc1847cf3 Image: jenkins/jenkins:2.426.1-jdk11 Image ID: docker.io/jenkins/jenkins@sha256:b470bcdc4ecd6651ef74a64ef4307be6d10fed7356500233fd62150da190c4c7 Ports: 8080/TCP, 50000/TCP Host Ports: 0/TCP, 0/TCP Args: --httpPort=8080 State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Sat, 16 Dec 2023 13:25:28 +0900 Finished: Sat, 16 Dec 2023 13:25:41 +0900 Ready: False Restart Count: 52 Limits: cpu: 1 memory: 700Mi Requests: cpu: 1 memory: 700Mi Liveness: http-get http://:http/login delay=0s timeout=5s period=10s #success=1 #failure=5 Readiness: http-get http://:http/login delay=0s timeout=5s period=10s #success=1 #failure=3 Startup: http-get http://:http/login delay=0s timeout=5s period=10s #success=1 #failure=12 Environment: ``` 落ちている原因はOOM Killerが発動している https://wiki.jenkins.io/JENKINS/3309623.html 上記のURLの1番目の項目のヒープについての調査を行う。 jenkins.yamlのenvを確認 ``` env: - name: SECRETS value: /run/secrets/additional - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: JAVA_OPTS value: >- -Dcasc.reload.token=$(POD_NAME) -Xms4000m - name: JENKINS_OPTS value: >- --webroot=/var/jenkins_cache/war - name: JENKINS_SLAVE_AGENT_PORT value: "50000" - name: CASC_JENKINS_CONFIG value: /var/jenkins_home/casc_configs ``` Javaヒープの最低サイズが4gbに設定されている。ただ700mbしか割り当てられていないので動かない。 ``` Limits: cpu: 1 memory: 700Mi Requests: cpu: 1 memory: 700Mi ``` よって、最低サイズを256mbに修正する。 ``` value: >- -Dcasc.reload.token=$(POD_NAME) -Xms256m ``` オリジナルのjenkins.yamlの差分 ``` diff -u jenkins.yaml jenkins.yaml.original --- jenkins.yaml 2023-12-16 14:07:17.327695044 +0900 +++ jenkins.yaml.original 2023-12-16 13:52:48.297865218 +0900 @@ -379,7 +379,7 @@ fieldPath: metadata.name - name: JAVA_OPTS value: >- - -Dcasc.reload.token=$(POD_NAME) -Xms256m + -Dcasc.reload.token=$(POD_NAME) -Xms4000m - name: JENKINS_OPTS value: >- --webroot=/var/jenkins_cache/war ``` `kubectl apply -f jenkins.yaml`で変更点を適応させる ``` NAME READY STATUS RESTARTS AGE jenkins-0 2/2 Running 0 4m49s ``` podが起動し、ブラウザでの確認ができた。 > http://localhost:31560 <a id="3"></a> 3. BGPがEstablishedにならない [TOP](#top) | ホスト名 | コマンド | ユーザ | パスワード | ポート | | -------- | -------- | -------- |-------- |-------- | | vyos00 | ```shell ssh user@192.168.255.90 -p 22``` | user | rgv8qbaiTVgg | 22 | | vyos01 | ```shell ssh user@192.168.255.91 -p 22``` | user | rgv8qbaiTVgg | 22 | ## 問題文 ``` あなたはとある会社で勤務している社会人です。あなたはあなたのチーム内のとある社員に対して、下記の課題を出していました。「vyos00内に存在する既存のeBGPの設定をdefaultからVRF EBGP-AS65001に移行してほしい」後日、課題を出していた社員から「BGPの設定変更は完了しているはずなのにeBGPが確立できない」と相談されました。この問題を解決してあげてください。 vyos00のeBGPに使用する情報は以下となっています local as remote as local interface local address remote address 65000 65001 dum0 1.1.1.1 2.2.2.2 ``` ## 前提条件特になし ## 制約 vyos01の設定変更禁止設定確認等の目的でvyos01にログインしていただくのは問題ありません ## 初期状態 vyos00の下記コマンド出力にて「Active」と表示されること > show ip bgp vrf EBGP-AS65001 neighbors 2.2.2.2 | grep state 表示例 > user@vyos00:~$ show ip bgp vrf EBGP-AS65001 neighbors2.2.2.2 | grep state BGP state = Active ## 終了状態 vyos00の下記コマンド出力にて「Established」と表示されること >show ip bgp vrf EBGP-AS65001 neighbors 2.2.2.2 | grep state 表示例 ※xには0~9の数字が入ります。 > user@vyos00:~$ show ip bgp vrf EBGP-AS65001 neighbors 2.2.2.2 | grep state BGP state = Established, up for xx:xx:xx > vyos00 ![image](https://hackmd.io/_uploads/SJo0w3qIT.png) > show configuration ```shell vrf { name EBGP-AS65001 { protocols { bgp { neighbor 2.2.2.2 { address-family { ipv4-unicast { } } ebgp-multihop 2 remote-as 65001 update-source 1.1.1.1 } parameters { router-id 1.1.1.1 } system-as 65000 } } table 100 } } ``` > vyos01 > ![image](https://hackmd.io/_uploads/HkOmO3cU6.png) > show configuration ``` protocols { bgp { neighbor 1.1.1.1 { address-family { ipv4-unicast { } } ebgp-multihop 2 remote-as 65000 update-source 2.2.2.2 } parameters { router-id 2.2.2.2 } system-as 65001 } static { route 1.1.1.1/32 { next-hop 10.0.0.1 { interface eth1 } } route 192.168.100.0/24 { next-hop 192.168.255.254 { interface eth0 } } } ``` > dummy らしい ![image](https://hackmd.io/_uploads/H1ZQzaqUa.png) ## LOG > Routing Table確認 ( vyos00) ![image](https://hackmd.io/_uploads/SJ2ya2c8a.png) > VRF Routing Table確認 > show ip route vrf EBGP-AS65001 ないらしい ![image](https://hackmd.io/_uploads/Hky9pnqLa.png) VRF 確認 ![image](https://hackmd.io/_uploads/Hy0O1p5Lp.png) よくわからんが、bgpコマンドないらしい ![image](https://hackmd.io/_uploads/ByWS7T9IT.png) > 推測 : 多分defaultで設定されているの反映されていないのかもしれない ![image](https://hackmd.io/_uploads/Byg6ET98p.png) コマンドログを見る限りはあってそう ```shell user@vyos00:~$ sh conf com | grep bgp set protocols bgp neighbor 2.2.2.2 remote-as '65001' set protocols bgp system-as '65000' set vrf name EBGP-AS65001 protocols bgp neighbor 2.2.2.2 address-family ipv4-unicast set vrf name EBGP-AS65001 protocols bgp neighbor 2.2.2.2 ebgp-multihop '2' set vrf name EBGP-AS65001 protocols bgp neighbor 2.2.2.2 remote-as '65001' set vrf name EBGP-AS65001 protocols bgp neighbor 2.2.2.2 update-source '1.1.1.1' set vrf name EBGP-AS65001 protocols bgp parameters router-id '1.1.1.1' set vrf name EBGP-AS65001 protocols bgp system-as '65000' ``` BGP周りの設定ができてそうなので、Vyos自体の設定に問題がありそう `eBGPの設定をdefaultからVRF EBGP-AS65001に移行してほしい` この書き込み的に、default設定がおかしいはずだが、、 interface dum0にvrfを設定してみたがダメだった ![image](https://hackmd.io/_uploads/ByKNYT9Ua.png) Routing tableがないのもおかしい全部eth1 ( 1.0.0.0.1 ) に投げて見る ![image](https://hackmd.io/_uploads/Hk50Ka5Ua.png) ダメだったが、Routingはできてそう到達不能がわからん ![image](https://hackmd.io/_uploads/Hy98qp9Up.png) 現状 > EBGP-AS65001はACTIVEのままでピアははれない > 2.2.2.2のネイバーにはping可能 > vrf指定でpingは不可能 interfaceではなく, ipに振ってみる > set vrf name EBGP-AS65001 protocols static route 0.0.0.0/0 next-hop 1.1.1.1 vrf EBGP-AS65001 interfaceではなく,自分に投げても意味ないので修正 > set vrf name EBGP-AS65001 protocols static route 0.0.0.0/0 next-hop 1.0.0.1 vrf EBGP-AS65001 > delete vrf name EBGP-AS65001 protocols static route 0.0.0.0/0 next-hop 1.1.1.1 vrf EBGP-AS65001 vyos01から ping 1.1.1.1に届かない ``` user@vyos01:~$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Net Unreachable From 10.0.0.1 icmp_seq=2 Destination Net Unreachable From 10.0.0.1 icmp_seq=3 Destination Net Unreachable From 10.0.0.1 icmp_seq=4 Destination Net Unreachable ``` > 192.168.255.91に設定してみる routing > set vrf name EBGP-AS65001 protocols static route 0.0.0.0/0 next-hop 192.168.255.91 vrf EBGP-AS65001 ## 再起動後 > configure > set interface dummy dum0 vrf EBGP-AS65000 > set vrf EBGP-AS65000 bint-to-call 1.1.1.1は行けるようになった ``` user@vyos00:~$ ping 1.1.1.1 vrf EBGP-AS65001 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.087 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.059 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=0.062 ms ``` eth1のインターフェイスにvrfを登録してdummyを広報すればいいだけだった.. <a id="4"></a> # 4. 絵文字が入力できない！😭 [nao](#nao) ## 問題文概要「我が社では古の時代から redmine を運用してきたが、最近入社した新卒から絵文字が書き込めないという問い合わせが寄せられるようになった。(;´･ω･｀) 私はこの通り書き込めているのだが...( -᷄ω-᷅ ) 君にはこの問題を解決してほしい<(￣＾￣)>」「上司、それは絵文字では無く顔文字です😓」 redmine に絵文字を書き込むことが出来ない事象を解決してください。 ## LOG ``` user@redmine:~$ sudo ss -tuln Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process udp UNCONN 0 0 127.0.0.1:323 0.0.0.0:* udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* udp UNCONN 0 0 [::1]:323 [::]:* tcp LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* tcp LISTEN 0 4096 0.0.0.0:3000 0.0.0.0:* tcp LISTEN 0 4096 [::]:80 [::]:* tcp LISTEN 0 128 [::]:22 [::]:* tcp LISTEN 0 4096 [::]:3000 [::]:* user@redmine:~$ ps aux | grep 3000 root 937 0.0 0.9 1008292 9476 ? Sl Dec15 0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3000 -container-ip 172.18.0.3 -container-port 3000 root 942 0.0 0.5 1155756 5576 ? Sl Dec15 0:00 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 3000 -container-ip 172.18.0.3 -container-port 3000 999 980 0.0 15.7 616256 154308 ? Ssl Dec15 0:15 puma 6.3.1 (tcp://0.0.0.0:3000) [redmine] user 3922 0.0 0.2 6608 2408 pts/0 S+ 15:38 0:00 grep --color=auto 3000 user@redmine:~$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE redmine latest 7c4524c4464e 2 months ago 666MB nginx latest 61395b4c586d 2 months ago 187MB mysql 5.7 92034fe9a41f 4 months ago 581MB ``` mysqlにutf8mb4を設定 Redmineの設定ファイル（通常はconfiguration.ymlまたはconfiguration.yaml）を確認して、絵文字関連の設定が正しく行われているか確認してください。 <a id="5"></a> # 5. ログが転送できない！ [sif](#sif) ## 問題文概要あなたはとある会社で勤務している社会人です。あなたのチームではサーバの監視システムを構築していますが、上司から「ログが転送できないから、転送できるように設定を修正してくれないか？」と相談されました。この問題を解決してあげてください。ログ収集システム構成今回あなたのチームでは、Grafana, Loki, promtailを用いてログ収集基盤を構築しようとしています。 ## LOG rsyslogの設定を確認 ``` user@server01:~$ cat /etc/rsyslog.d/80-ictsc.conf # # Forward log to remote server # *.* @192.168.255.11:5514 ``` 設定がtcpモードになっていたためudpでの設定に変更 ``` *.* @@192.168.255.11:5514 ``` promtailの設定を確認 ``` user@server01:~$ sudo cat /etc/promtail/config.yml server: http_listen_address: 192.168.255.11 http_listen_port: 30003 grpc_listen_address: 192.168.255.11 grpc_listen_port: 30004 positions: filename: /tmp/positions.yaml clients: - url: http://192.168.255.11:30001/loki/api/v1/push scrape_configs: - job_name: syslog syslog: listen_address: 192.168.255.11:5514 listen_protocol: udp labels: job: syslog relabel_configs: - source_labels: ['__syslog_message_hostname'] target_label: 'hostname' - source_labels: ['__syslog_message_severity'] target_label: 'severity' - source_labels: ['__syslog_message_facility'] target_label: 'facility' ``` lokiの設定を確認（省略している） ``` user@server01:~$ sudo cat /etc/loki/config.yml server: http_listen_address: 192.168.255.11 http_listen_port: 30001 grpc_listen_address: 192.168.255.11 grpc_listen_port: 30002 common: instance_addr: 192.168.255.11 path_prefix: /tmp/loki storage: filesystem: chunks_directory: /tmp/loki/chunks rules_directory: /tmp/loki/rules replication_factor: 1 ring: kvstore: store: inmemory query_range: results_cache: cache: embedded_cache: enabled: true max_size_mb: 100 ``` sudo vim /etc/sysctl.conf ``` net.ipv4.ip_forward = 1 ``` を追加 <a id="5"></a> 5. 奴の名は [TOP](#top) ## 問題文 ## LOG 問題 <a id="6"></a> # 1.経路がおかしい [TOP](#top) ## 問題文 ``あなたは、VyOS02の管理者です。 VyOS01とVyOS03はBGPピアとして接続され、経路制御を行っています。ある日、VyOS01のネットワーク(172.16.1.1)にtracerouteをしたところ、VyOS03を経由して到達していることが分かりました。 `` そのため、VyOS01, VyOS03ともに迂回しない経路に変更してください。 ### 前提条件 vyos01, vyos03の設定は正しく行われている vyos02で適切な設定を行うことで本トラブルは解決する問題回答者はvyos02のみ操作可能 ### 初期状態すべてのアドレスにpingによる通信が可能 vyos02からping 172.16.1.1を実行した場合、vyos02 → vyos03 → vyos01の経路が選択される ### 終了状態 172.16.1.0/24のネクストホップが10.10.1.1であること 172.16.3.0/24のネクストホップが10.10.3.3であることよって、vyos02からping 172.16.1.1を実行した場合、vyos02 → vyos01の経路が選択されるようになる ## LOG インターフェースに適切なipが振られているか確認 ``` show interfaces dummy dum0 { address 172.16.2.1/24 } ethernet eth0 { address 192.168.255.62/24 hw-id 9c:a3:ba:32:12:12 } ethernet eth1 { address 10.10.1.2/24 hw-id 9c:a3:ba:32:3a:d1 } ethernet eth2 { address 10.10.3.2/24 hw-id 9c:a3:ba:32:05:92 } loopback lo { } ``` 172.16.1.0/24のNext hopを確認 ``` show ip bgp BGP table version is 1707, local router ID is 192.168.255.62, vrf id 0 Default local pref 100, local AS 65002 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 10.10.3.3 0 65003 65001 i *> 172.16.2.0/24 0.0.0.0 0 32768 i *> 172.16.3.0/24 10.10.3.3 0 0 65003 i Displayed 3 routes and 3 total paths ``` bgpの設定ができているか確認 ``` show protocols bfd { peer 10.10.1.1 { echo-mode interval { echo-interval 10 multiplier 2 receive 10 transmit 10 } } peer 10.10.3.3 { echo-mode interval { echo-interval 10 multiplier 2 receive 10 transmit 10 } } } bgp { address-family { ipv4-unicast { network 172.16.2.0/24 { } } } neighbor 10.10.1.1 { address-family { ipv4-unicast { } } bfd { } remote-as 65001 } neighbor 10.10.3.3 { address-family { ipv4-unicast { } } bfd { } remote-as 65003 } system-as 65002 timers { holdtime 180 keepalive 60 } } static { route 192.168.100.0/24 { next-hop 192.168.255.254 { } } } ``` ``` root@vyos02:~# show protocols static arp interface eth1 Address HWtype HWaddress Flags Mask Iface 10.10.1.3 (incomplete) eth1 10.10.1.1 ether 9c:a3:ba:32:39:94 C eth1 ``` 10.10.1.3とかいう謎のIPがあるこれを消せばいいのでは？と思い様々なコマンドを5億通り打ってみたが、全く消えない、時間切れ <a id="7"></a> 6. なんか通信できない(´・ω・｀) [TOP](#top) ## 問題文とある企業ではネットワーク機能を含めlinuxで構築しており、あなたはdepartment-A、及びrouterの管理者である。ある日、電源トラブルによってサーバ群の再起動が発生したところ、department-Aからdepartment-Bに対して通信ができなくなってしまった。過去のrouter管理者に確認すると、department-Aからdepartment-Bの通信は「IPアドレスを変換」して通信を行っていたようだ。あなたにはdepartment-Aからdepartment-Bへ通信を出来るようにしてほしい。また、今後このようなことが起きないように再起動しても通信できるとありがたい。 ※前提条件特になし ### ネットワーク図 ![image](https://hackmd.io/_uploads/By8_J65Ua.png) ### 制約 * department-A、及びrouterにログイン可能 * department-Bにログイン不可 * ネットワークを制御するプロトコルの一部または全ての機能に関する無効化の禁止 ## LOG ### department-A & router OS ``` [user@department-A ~]$ cat /etc/os-release NAME="AlmaLinux" VERSION="9.2 (Turquoise Kodkod)" ID="almalinux" ID_LIKE="rhel centos fedora" VERSION_ID="9.2" PLATFORM_ID="platform:el9" PRETTY_NAME="AlmaLinux 9.2 (Turquoise Kodkod)" ANSI_COLOR="0;34" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos" HOME_URL="https://almalinux.org/" DOCUMENTATION_URL="https://wiki.almalinux.org/" BUG_REPORT_URL="https://bugs.almalinux.org/" ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9" ALMALINUX_MANTISBT_PROJECT_VERSION="9.2" REDHAT_SUPPORT_PRODUCT="AlmaLinux" REDHAT_SUPPORT_PRODUCT_VERSION="9.2" ``` ### department-A にスタティックルートの設定 ``` [root@department-A ~]# ip route add 192.168.50.4/30 via 192.168.50.2 dev eth1 [root@department-A ~]# ip route 192.168.50.0/30 dev eth1 proto kernel scope link src 192.168.50.1 metric 101 192.168.50.4/30 via 192.168.50.2 dev eth1 192.168.100.0/24 via 192.168.255.254 dev eth0 proto static metric 100 192.168.255.0/24 dev eth0 proto kernel scope link src 192.168.255.50 metric 100 [root@department-A ~]# ping 192.168.50.6 PING 192.168.50.6 (192.168.50.6) 56(84) bytes of data. 64 bytes from 192.168.50.6: icmp_seq=1 ttl=64 time=0.419 ms 64 bytes from 192.168.50.6: icmp_seq=2 ttl=64 time=0.314 ms 64 bytes from 192.168.50.6: icmp_seq=3 ttl=64 time=0.303 ms 64 bytes from 192.168.50.6: icmp_seq=4 ttl=64 time=0.373 ms ^C --- 192.168.50.6 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3108ms rtt min/avg/max/mdev = 0.303/0.352/0.419/0.046 ms ``` routerのeth2までは通るようになったがdepartment-Bまで行かない IPアドレスの変換ができていない？ department-Aにデフォルトゲートウェイを追加 ``` sudo nmcli connection modify "Wired connection 1" ipv4.gateway 192.168.50.2 ``` インターフェースの再起動 ``` nmcli connection down "Wired connection 1" ``` ``` nmcli connection up "Wired connection 1" ``` 適用できたか確認 ``` nmcli device show eth1 GENERAL.DEVICE: eth1 GENERAL.TYPE: ethernet GENERAL.HWADDR: 9C:A3:BA:32:A5:D9 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: Wired connection 1 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/4 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 192.168.50.1/30 IP4.GATEWAY: 192.168.50.2 IP4.ROUTE[1]: dst = 192.168.50.0/30, nh = 0.0.0.0, mt = 101 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.50.2, mt = 101 IP6.ADDRESS[1]: fe80::82ed:a4ce:7fac:3bf9/64 IP6.GATEWAY: -- IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 1024 ``` <a id="8"></a> 6. 奴の名は [TOP](#top) ## 問題文 ## LOG <a id="9"></a> 9. hkk [TOP](#top) ## 問題文 ### 問１イーサネット通信にあたり必要なメタル線の最低本数は何本か。 2本 O 4本 6本 8本 ### 問２ IP電話において、ユーザーの電話機が着信中であることを示すSIPメッセージのステータスコードはなにか。 100 180 O 200 304 ### 問３ Ubuntu 22.04 における標準的な nginx のセットアップにおいて、 /var/log/nginx/error.log に以下のようなエラーが記録されていた。 ``` # cat error.log yyyy/mm/dd HH:MM:ss [crit] 1234#1234: accept4() failed (24: Too many open files) ``` このエラーに対する最も適切な対応は以下のうちどれか `ulimit -u unlimited` コマンドを実行する systemd unit file において `LimitNOFILE` を設定する O `/etc/security/limits.conf` において適切な値をセットする `systemctl set-environment LimitNOFILE=unlimited` コマンドを実行する ### 問４あるWebサーバーの負荷試験を行うため、クライアントとサーバーとなるLinuxがインストールされたVMを1台ずつ用意した。負荷の実行元であるクライアントのIPアドレスは192.0.2.1、サーバーのアドレスはhttp://192.0.2.2 とし、通信にはHTTP/1.1プロトコルを用いるものとした。クライアントおよびサーバーの処理性能が十分であり、OS等の設定も十分にチューニングされているとき、クライアントがサーバーに対して接続可能な同時接続数は最大何件か。数千件程度数万件程度数十万件程度 O 数百万件程度 ### 問５ Amazon Web Services (AWS) の Elastic Compute Cloud (EC2) において、あるインスタンスにアタッチされた Elastic Block Store (EBS) ボリュームのスナップショットを取得した。このスナップショットを元に新たなEBSボリュームを作成し、元のボリュームより高いIO性能(IOPS)を指定し同一リージョン上の異なるEC2インスタンスにアタッチした。この直後に作成後のボリュームにアクセスしたところ、設定したIO性能より大幅に低い性能しか得ることができなかったが、これはなぜか。最も適切と考えられる選択肢を選べ。なお、上記手順の実施は連続して行い、ここで明示された手順を達成するための最小の操作のみを実行したものとする。 AWS EC2では元のEBSボリュームのIO性能が新しいボリュームにも反映されるから。インスタンス内でEBSボリュームのIO性能を変更するコマンドを実行する必要があるから AWS EC2ではボリュームのIO性能の設定変更に時間を要するから　O 作成直後のEBSボリュームは十分な性能が出ないから ### 問６現在、4GやWi-Fiの多くの無線通信方式において採用されている変調方式であるOFDMでは、各サブキャリアを密に配置することで、限られた周波数帯を有効に活用している。そのOFDMにおける特徴として、正しくないものはどれか。各サブキャリアではQAMのような変調方式を利用して変調を行う送信時にIFFT(逆フーリエ変換)、受信時にFFT(フーリエ変換)を利用してデジタル信号との変換を行う各サブキャリアを各端末にそれぞれ割り当てることで、伝送効率を最大限に高めることができる O 各サブキャリアは位相が90度ずれており、これによりサブキャリアを密に配置することが可能になっている ### 問７ L4の輻輳制御における以下の記述のうち、正しいものはどれか BBRはCongestion-based輻輳制御アルゴリズムと呼ばれ、ECN(Explicit Congestion Notification)機能を用いて輻輳制御を行う HTTP/1.1 や HTTP/2 はTCP上のプロトコルであり輻輳制御が行われるが、HTTP/3 はUDP上のプロトコルであるため輻輳制御が行われない NewRenoはLoss-basedの輻輳制御アルゴリズムの1つであり、同時に存在する他のコネクションより大きな帯域を得るためにウィンドウサイズを逐次調整する輻輳制御アルゴリズムである TCP上のLoss-based輻輳制御アルゴリズムは、パケットロスを検出したときにウィンドウサイズを縮小することで輻輳を回避し、パケットロスの発生を回避しようとする O ### 問８ systemd timer において毎朝8時ちょうどに systemd unit を実行したいとき、OnCalendar に設定すべき内容は以下のどれか `*-* 8:0` O `*-*-* */8:0:0` `0:0:8 *-*-*` 以上のどれも正しくない ### 問９以下はあるLinuxのサーバーにおいてコマンドを実行した結果である。 1回目と2回目のコマンド実行において、実行時間が大きく変化した理由はなぜか、最も適切なものを選べ。なお、ファイルの内容は 0 (0x00) が連続しているファイルで、検証に用いた環境は市販されているPCI Express 3.0 に対応した M.2 SSD である。 ``` $ ls -lh testfile -rw-rw-r-- 1 user user 1000M Oct 15 00:37 testfile # 1回目 $ time cat testfile > /dev/null cat testfile > /dev/null 0.00s user 0.50s system 41% cpu 1.201 total # 2回目 $ time cat testfile > /dev/null cat testfile > /dev/null 0.00s user 0.18s system 99% cpu 0.184 total ``` 1回目の実行ではcpuが41%しか使い切れておらず、十分にリソースを利用できていなかったからファイルの内容がSSDのキャッシュメモリに配置されたから O ファイルの内容が0であり、ファイルのの内容が自動で圧縮されたから 1-3のどれも適切でない 1-3のどれも正しい ### 問１０ Ethernetにおいて通信の衝突を防ぐ仕組みの1つである CSMA/CD 方式における以下の説明のうち、正しくないものはどれか選べ。 Wi-Fi においては、CSMA/CD 方式による衝突検出は不要である O 通信が衝突した場合にはランダムな時間だけ待つことにより、クライアント同士の通信が衝突することを回避することができる CSMA/CD 方式では、実際の通信を始める前に制御フレームを送信することにより、他のクライアントが通信しないことを確認するリピータハブを用いない場合にはCSMA/CDを用いなくても通信の衝突は生じない ## LOG <a id="8"></a> 10. HKA [TOP](#top) ## 問題文 ### 問1 以下のうち eBPF の説明として間違っているものはどれか？ - eBPF は Linux カーネルの任意の箇所にプログラムをアタッチすることが出来る機能である。同じ機能を持つカーネルモジュールと比べた eBPF の利点として、アタッチされるプログラムは実行時にエラーを起こしカーネルが異常終了することが無いことが挙げられる - eBPF プログラムをアタッチする前に、「ループがないこと」「未初期化レジスタを利用していないこと」など実行時エラーを引き起こさないコードであることがユーザ空間内で検証される - eBPF を利用した技術の一つに XDP がある。XDP はパケット処理をすべてカーネル空間内で行うことにより従来の Linux カーネルネットワーキングよりもパケットを高速に転送することができる - ユーザ空間で動作するプロセスと eBPF プログラムとのやり取りには eBPF Map と呼ばれるデータ構造が利用される A. eBPF は Linux カーネルの任意の箇所にプログラムをアタッチすることが出来る機能である。同じ機能を持つカーネルモジュールと比べた eBPF の利点として、アタッチされるプログラムは実行時にエラーを起こしカーネルが異常終了することが無いことが挙げられる問2 以下の正規表現にマッチしない文字列はどれか？ ^I.T.C[0-9]{,4}$ - `ICTSC2023` - `IXTXC2023` - `ICTSC9` - `ICTSC10000` A. `ICTSC10000` ### 問3 以下の文字列にマッチしない正規表現はどれか？ !!! WELLCOME TO ICTSC 2023 !!! - `^\D+\d+\D+$` - `^(\S+\s+)*$` - `^(\S{3}).*\1$` - `^[^2].*\d` A. `^[^2].*\d` ### 問4 Kubernetes の説明として誤っているものはどれか？ - NetworkPolicy リソースを利用することで Pod を Kubernetes クラスタの外部に公開することができる。 - ReplicaSet リソースを利用することで Pod のスケールアウトを行うことができる。 - ResourceQuota リソースを利用することで Pod の利用する memory 量を制限することができる。 - DaemonSet リソースを利用することで Pod をすべての Node に配置することができる。 A.NetworkPolicy リソースを利用することで Pod を Kubernetes クラスタの外部に公開することができる。 ### 問5 一般的に CI/CD (Continuous Integration/Continuous Delivery) を行うためのツールの1つとされている OSS は以下のうちどれか？ - Jupyter Notebook - Jenkins - Kubernetes - Istio A. Jenkins ### 問6 サービスメッシュを利用することで実現できることの説明として間違っているものはどれか？ - アプリケーションのソースコードに手を加えずに、そのアプリケーションが行う通信の経路を暗号化することができる。 - 通信先マイクロサービスの増加による end-to-end 通信 (ユーザ視点でリクエストしてからレスポンスが返ってくるまでの通信) の遅延の課題を解決することができる。 - あるマイクロサービスにてバーストトラフィックが発生した際にカスケード障害 (連鎖的に別マイクロサービスに障害が発生すること) を防ぐことができる。 - マイクロサービス間の通信の可視化をすることができる。 A. - アプリケーションのソースコードに手を加えずに、そのアプリケーションが行う通信の経路を暗号化することができる。 ## LOG <a id="9"></a> 11. hkn [TOP](#top) ## 問題文 ### 問１以下のIPのうち、 10.0.4.0/22 のホストアドレスに含まれないものはどれか。 10.0.4.1 10.0.5.255 10.0.6.0 10.0.7.255 A. 10.0.6.0 ### 問２下図はIP(Internet Protocol)v4のヘッダフォーマットを示している。 ![image](https://hackmd.io/_uploads/BJ6eFs5I6.png) (数値はBitを表している。) ヘッダフィールドA,B,Cについて正しいフィールド名はどれか。 IPv4の仕様はIETFより公開されているRFC 791 「INTERNET PROTOCOL」に記載されている。 A Version　○ Identification Protocol Flags B IHL Total Length Time to Live ○ Header Checksum C Type of Service Fragment Offset Source Address Destination Address ○ ### 問３端末からネットワーク機器に対してtelnetでリモートからアクセスを試みた。ネットワーク上を流れるデータはプロトコルによる階層構造となっている。下図に示す構造のうち、それぞれA,B,Cはどのプロトコルのヘッダとなっているか選択肢より答えよ。 ![image](https://hackmd.io/_uploads/rJNyFi9Lp.png) A UDP IP TCP　○ Ethernet B UDP IP ○ TCP Ethernet C UDP IP TCP Ethernet ○ ### 問４次のうち、DHCPv6にて行えないものはどれか。デフォルトゲートウェイのアドレスを通知する。 DNSサーバのアドレスを通知する。 SIPサーバのドメイン名を通知する。　○ 端末のインターフェイスに割り当てるためのIPv6ユニキャストアドレスを通知する。 ### 問５次に示す選択肢のうち、オフィスなど屋内高密度の無線LAN環境において、スループットの低下を防ぐために有効な方法はどれか。 APの電波出力を高くする全てのAPで同一のチャネル帯を利用する端末においてローミングの閾値（RSSI）を低い値にする APにて低データレートでの接続を許可しない　○ ### 問６以下の送信経路の時、TCP 3way Handshakeによって確立されたコネクションにおいて端末から送信するセグメントの最大サイズとサーバから送信するセグメントの最大サイズの組み合わせとして正しいものを選べ。 ![image](https://hackmd.io/_uploads/B1XR_icLa.png) 端末からサーバへの経路 Client => R1 => R3 => R4 => Server サーバからクライアントへの経路 Server => R4 => R2 => R1 => Clinet 図中のAdjust MSSはTCPのMSSオプションフィールドに挿入する値である。各ルータのAdjust MSSは全てのインターフェイスにて使用される値である。端末：1460, サーバ：1400 端末：1460, サーバ：1460 端末：1500, サーバ：1500 端末：1400, サーバ：1400 端末：1400, サーバ：1460 ○ 端末：1460, サーバ：1500 ## LOG <a id="10"></a> 12. HKP [TOP](#top) ## 問題文 ### 問1 以下のプロトコルのうち、一般的にUDPを用いるプロトコルはどれか？ - SSH - RTP - FTP - LLDP A. RTP ### 問2 ルートリフレクタに関する以下の記述のうち、正しいものはどれか？ - ルートリフレクタを使用する場合、そのAS内では全てのルータがルートリフレクタとピアを張る必要がある。 - ルーティングループを防ぐため、ルートリフレクタがあるiBGPピアから受け取った経路を別のクライアントに転送する際には、NEXT_HOP, AS_PATH, LOCAL_PERF, MEDを書き換えずに転送する必要がある。 - ルートリフレクタクライアントは自身がルートリフレクタクライアントであることを知る必要があり、ルートリフレクタとのOPENメッセージで交換されるCapabilityを通じて、自身がルートリフレクタクライアントであることを知ることができる。 - 1台のルートリフレクタが故障した際に備え、ルートリフレクタを複数台用意し、クラスタ構成にすることがある。その際、その構成内の全てのルートリフレクタは同じORIGINATOR_IDを使うように設定される必要がある。 A.ルートリフレクタを使用する場合、そのAS内では全てのルータがルートリフレクタとピアを張る必要がある。 ### 問3 Linux VRFに関する以下の記述のうち、正しいものはどれか？ - Linux VRFはPolicy Based Routingの技術を用いて実現されている。そのため、VRFデバイスに関連付けられたルーティングテーブルに適切な経路がない場合、そのVRFデバイスに関連付けられたパケットは「経路が見つからなかった」として破棄される。 - ある特定のVRFの中でパケットを待ち受けしたい場合、VRFデバイスとソケットを紐付ける必要がある。その際、VRFデバイスに紐付けられていないソケットは、VRFデバイスに紐付けられていないインターフェースから受信したパケットのみを受け付けることができる。 - 複数のVRFデバイスが同じルーティングテーブルに関連付けられた場合、紐付けられたVRFデバイスが異なるものであったとしても、それらのVRFデバイスに紐付けられたインターフェース間でパケットは転送される。 - VRFデバイスが紐付けられたインターフェースから受信したパケットをiptablesのINPUTチェインでフィルタリングしたい場合、入力デバイスの指定 `-i` にはVRFデバイス名を指定するのではなく、インターフェース自体の名前を指定しなければならない。 A. ある特定のVRFの中でパケットを待ち受けしたい場合、VRFデバイスとソケットを紐付ける必要がある。その際、VRFデバイスに紐付けられていないソケットは、VRFデバイスに紐付けられていないインターフェースから受信したパケットのみを受け付けることができる。 ### 問4 あなたはクラウド事業者である。ある日、ユーザから「ロードバランサー経由の通信だけがなぜか上手くいかない。VMではパケットを確認することができるが、クライアントでは応答を受け取ることができない。」という問い合わせを受けた。VMを収容しているハイパーバイザーの問題として最も考えられる問題はどれか？ただし、ハイパーバイザーとしてLinux (QEMU + KVM)を使用しており、ロードバランサーはパフォーマンスを向上させるため、L4LB(L3DSR)構成を取っている。 - net.ipv4.conf.all.rp_filterの設定が適切でない。 - net.ipv4.conf.all.forwardingの設定が適切でない。 - net.ipv4.fib_multipath_hash_policyの設定が適切でない。 - net.netfilter.nf_conntrack_maxの設定が適切でない。 A. net.ipv4.conf.all.forwardingの設定が適切でない ### 問5 OpenRoamingはこれまでの公衆無線LANにおける問題を解決するために推進されている技術である。このOpenRoamingに関する以下の記述のうち、正しいものはどれか？ - OpenRoamingでは、端末にインストールされるプロファイルに、あらかじめESSIDを記載することによって、公衆無線LANの認証を行うため、端末ごとに複数のプロファイルをインストールしておく必要がある。 - OpenRoamingでは、端末の認証をする際に、GoogleアカウントやSIMの情報を用いて認証を行うことができる。 - OpenRoamingは比較的新しいプロトコルのため、2.4GHz帯を使用する端末では使用することはできない。 - 以上のどれも正しくない。 A. OpenRoamingでは、端末にインストールされるプロファイルに、あらかじめESSIDを記載することによって、公衆無線LANの認証を行うため、端末ごとに複数のプロファイルをインストールしておく必要がある ### 問6 Segment Routingに関する以下の記述のうち、正しくないものはいくつ存在するか？ - MPLSでは、仕様上Ethernetフレームをカプセリングすることができないため、SR-MPLSではL2VPNを実現することはできず、SRv6を使用する必要がある。 - SR-MPLSでは、一般的なMPLSのデプロイメントに必要なLDPを使用せずに、IGPのみでラベルの配布が可能である。複雑なポリシーを実現するためには、BGPやPCEPなどのプロトコルを併用して実現することができる。 - SRv6では、パケットをカプセリングするためにSegment Routing Headerを必ず使用する必要があり、SR-MPLSに比べてSegment Routingによるパケットのオーバーヘッドが非常に大きくなる。 - SRv6では、パケットがIPv6パケットによってカプセリングされるため、ECMPが使用できないという問題が知られている。そのため、SRv6の多くの実装では外側IPv6ヘッダーの送信元IPアドレスをランダムにする仕組みが実装されている。 - 1つ - 2つ - 3つ - 4つ A. 2つ ## LOG <a id="11"></a> 1. hki [TOP](#top) ## 問題文あるセキュリティコンテストにおいて、パケットキャプチャを取得した。全部で12チームが参加しており、攻撃の対象は 10.10.11.1 だった。しかし、それ以外のIPアドレスは全て 0.0.0.0 に書き換えられており、どこから送信されたのかわからなくなっている。このファイルを解析して、次の問いに答えよ。 ### 問１ IPアドレス 10.10.11.1 をもつホストにおいて、動作しているサービスのポート番号はどれか。複数ある場合は、最も通信量が多いものを答えよ。 80 443 33333 46345 59364 O ### 問２問1で答えたポートで動作しているサービスの説明として、最も適切なものを以下から選べ。標準的なHTTPプロトコルを介したアプリケーションが動作している。 O テキストベースのコマンドでノートを記録し、閲覧することができるアプリケーションが動作している。言語処理系のインタプリタが実装されており、その入力を受け付けるアプリケーションが動作している。あるファイル共有プロトコルを介してファイルのやりとりをするアプリケーションが動作している。 ### 問３問1,2で答えたアプリケーションに対して発生している攻撃はどれか。次のうちから該当するものを全て答えよ。パストラバーサル O バッファオーバーフローレースコンディション OSコマンドインジェクション HTTPヘッダインジェクション O ### 問４一番最初のパケット（1 2023-08-12 03:25:25.215874 0.0.0.0 10.10.11.1 TCP 78 49681 → 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1380 WS=64 TSval=3335658758 TSecr=0 SACK_PERM）について、IP層のヘッダーのチェックサムの値は何か。 0x0000 0x1a4a 0x3a9b O 0x8b93 ### 問５このキャプチャを取得した環境において、ネットワーク中に参加している端末の本来のIPは 10.0.{1-12}.{100-} の範囲である。問4のパケットについて、送信元の本来のIPアドレスは何か。 10.0.1.100 10.0.2.101 O 10.0.3.101 10.0.4.100 10.0.5.100 10.0.6.101 10.0.7.101 10.0.8.100 10.0.9.100 10.0.10.101 10.0.11.101 ### 問６このキャプチャにおいて、10.10.11.1 と最も多くのパケットを送受信したIPアドレスはどれか。 10.0.1.100 O 10.0.2.101 10.0.3.101 10.0.4.100 10.0.5.100 10.0.6.101 10.0.7.101 10.0.8.100 10.0.9.100 10.0.10.101 10.0.11.101 ## LOG <a id="120"></a> # 12. ファイルが送れないlog [TOP](#top) ## 問題文 ## LOG お世話になっております。チームK-Shir0に追いつけです。この問題は/dev/vdb1のinodeが不足していたのでトラブルが発生したと考えられました。そのため、以下のように設定を変更し、ファイル転送が正しく動くことを確認いたしました。ご確認のほどよろしくお願いいたします。 ## 手順 df -i でinodeのコマンドを ``` user@upload-site:~/storage$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 122560 633 121927 1% /run /dev/vda2 1310720 156228 1154492 12% / tmpfs 122560 1 122559 1% /dev/shm tmpfs 122560 3 122557 1% /run/lock /dev/vdb1 1280 1280 0 100% /home/user/storage tmpfs 24512 20 24492 1% /run/user/1002 ``` inodeが枯渇しているのが確認できる。よって、inodeを増やしていく。各ボリュームで使用中のファイルシステムを確認 ``` user@upload-site:~/storage$ df -hT Filesystem Type Size Used Avail Use% Mounted on tmpfs tmpfs 96M 920K 95M 1% /run /dev/vda2 ext4 20G 4.4G 15G 24% / tmpfs tmpfs 479M 0 479M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/vdb1 ext4 10G 56K 9.4G 1% /home/user/storage tmpfs tmpfs 96M 0 96M 0% /run/user/1002 ``` ext4なのでinodeを増やすことができないパーティションを確認 ``` user@upload-site:~/storage$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 disk ├─vda1 252:1 0 1M 0 part └─vda2 252:2 0 20G 0 part / vdb 252:16 0 20G 0 disk └─vdb1 252:17 0 10G 0 part /home/user/storage ``` vdbに10gb余っているのでそこにinodeが多いファイルシステムを構築し、元のファイルシステムからファイルをコピーしていく。ファイルシステムをアンマウント ``` sudo umount /dev/vdb1 ``` パーティションを作成 ``` Command (m for help): n Partition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions) Select (default p): Using default response p. Partition number (2-4, default 2): First sector (20973568-41943039, default 20973568): Last sector, +/-sectors or +/-size{K,M,G,T,P} (20973568-41943039, default 41943039): Created a new partition 2 of type 'Linux' and of size 10 GiB. Command (m for help): Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. ``` パーティションテーブルの更新: ``` sudo partprobe ``` ファイルシステムの作成 ``` user@upload-site:~$ sudo mkfs.ext4 -N 12800 /dev/vdb2 mke2fs 1.46.5 (30-Dec-2021) Creating filesystem with 2621184 4k blocks and 12800 inodes Filesystem UUID: e8afbad2-6116-4f7c-862b-d8c1903c7ce9 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done ``` ホームディレクトリに新たなディレクトリを作成 ``` user@upload-site:~$ mkdir storage2 ``` マウントする ``` sudo mount /dev/vdb1 /home/user/storage2 sudo mount /dev/vdb2 /home/user/storage ``` `df -i` で確認 ``` user@upload-site:~$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 122560 645 121915 1% /run /dev/vda2 1310720 156229 1154491 12% / tmpfs 122560 1 122559 1% /dev/shm tmpfs 122560 3 122557 1% /run/lock tmpfs 24512 20 24492 1% /run/user/1002 /dev/vdb1 1280 1280 0 100% /home/user/storage2 /dev/vdb2 12800 11 12789 1% /home/user/storage ``` storegeに全てファイルをコピーする ``` sudo cp -R /home/user/storage2/* /home/user/storage/ ``` ls -alで権限周りを確認 ``` user@upload-site:~$ ls -al total 116 drwxr-xr-x 7 user user 4096 Dec 16 16:41 . drwxr-xr-x 5 root root 4096 Oct 3 12:04 .. -rw------- 1 user user 1844 Dec 16 16:41 .bash_history -rw-r--r-- 1 user user 220 Jan 7 2022 .bash_logout -rw-r--r-- 1 user user 3850 Oct 3 12:06 .bashrc drwx------ 2 user user 4096 Oct 17 21:54 .cache -rw------- 1 user user 20 Dec 16 15:14 .lesshst -rw-r--r-- 1 user user 807 Jan 7 2022 .profile drwxr-xr-x 3 root root 36864 Dec 16 16:34 storage drwxr-xr-x 2 root root 4096 Dec 16 16:41 storage1 drwxrwxrwx 3 user user 36864 Oct 12 22:46 storage2 drwxr-xr-x 2 user user 4096 Dec 16 15:04 upload-site -rw------- 1 user user 821 Dec 16 15:04 .viminfo ``` よって chownとchmodを打つ ``` sudo chown user:user /home/user/storage chmod 777 storage ``` ls -alで確認 ``` user@upload-site:~$ ls -al total 116 drwxr-xr-x 7 user user 4096 Dec 16 16:41 . drwxr-xr-x 5 root root 4096 Oct 3 12:04 .. -rw------- 1 user user 1844 Dec 16 16:41 .bash_history -rw-r--r-- 1 user user 220 Jan 7 2022 .bash_logout -rw-r--r-- 1 user user 3850 Oct 3 12:06 .bashrc drwx------ 2 user user 4096 Oct 17 21:54 .cache -rw------- 1 user user 20 Dec 16 15:14 .lesshst -rw-r--r-- 1 user user 807 Jan 7 2022 .profile drwxrwxrwx 3 user user 36864 Dec 16 16:34 storage drwxr-xr-x 2 root root 4096 Dec 16 16:41 storage1 drwxrwxrwx 3 user user 36864 Oct 12 22:46 storage2 drwxr-xr-x 2 user user 4096 Dec 16 15:04 upload-site -rw------- 1 user user 821 Dec 16 15:04 .viminfo ``` 再起動した際にも同じ構成になるように/etc/fstabを編集 ``` # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/vda2 during curtin installation /dev/disk/by-uuid/4d8dbaf3-495f-4b09-ac6b-ba55b97d154d / ext4 defaults 0 1 /dev/vdb2 /home/user/storage ext4 defaults 0 0 /dev/vdb1 /home/user/storage2 ext4 defaults 0 0 ``` 再起動後、接続情報の手順をふみ、ブラウザからアップロードに成功する http://localhost:8086 # <a id="13"></a> 13. 奴の名は [TOP](#top) ## 問題文 ## LOG <a id="14"></a> 14. 奴の名は [TOP](#top) ## 問題文 ## LOG <a id="15"></a> 15. 奴の名は [TOP](#top) ## 問題文 ## LOG

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.