arashi1977さんの助け合いフォーラム投稿一覧
矛盾しないですね。
たとえば有線LANの環境をイメージしてもらいたいのですが
- ツイストペアケーブル（UTP/STP）と光ファイバーは互換性がない（＝周波数帯が異なる場合は通信できない）
- ツイストペアケーブルを使用する規格（Ethernet, FastEthernet, GigabitEthernet）には互換性がある
- カテゴリ5以上のツイストペアケーブルを使用して接続する場合、両端の装置で 802.3u や 802.3ab といった規格が一致しなければならない（＝同じ規格で通信する必要がある）
- GigabitEthernetのスイッチにFastEthernetのNICを持つ装置を繋いでも通信できるのは、GigabitEthernet（802.3ab対応）のスイッチが下位の規格であるFastEthernet（802.3u）にも対応しているため
というだけの話です。
参考）
802.3についてはこちら https://e-words.jp/w/IEEE_802.3.html
装置が単体で複数の規格に対応している例（Catalyst 9200）はこちら https://www.cisco.com/c/ja_jp/products/collateral/switches/catalyst-9200-series-switches/nb-06-cat9200-ser-data-sheet-cte-en.html#%E7%AE%A1%E7%90%86%E6%A9%9F%E8%83%BD%E3%81%8A%E3%82%88%E3%81%B3%E6%A8%99%E6%BA%96%E8%A6%8F%E6%A0%BC%E3%81%AE%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88
問題演習中はできないようになっていたかと思います。別ウィンドウで開いても現在演習中のセッションに復帰するので、そのやり方も多分ダメですね。
試験同様に「最後までやる」しかないですが、これも試験の練習だと思えば… (^^;
トラフィックが一致しているとアクションが実行されないのであれば、denyエントリは何のために存在するのでしょう？
シーケンス10では「アクセスリスト100にマッチしたら破棄」となっているので、「アクセスリストにマッチしないものは破棄しない」ということです。なので、明示的に「シーケンス10の処理対象としない（破棄させたくない）トラフィック」をdenyしておくことで、処理対象から外す、というのが存在する理由ですかね。
別の仕組みの名前を使うと「ホワイトリスト」「ブラックリスト」をどう実装しているか、です。
ACL100は拒否する対象を定義している「ブラックリスト」のように見えますが、VLANアクセスマップの中では「ACL100にマッチしたら破棄」となっており挙動としては「permitされたものが破棄される」ので、その逆の「denyエントリにマッチするものは破棄対象とならない」ことが確実になることから「ホワイトリスト」を定義していると理解されると良いのではないかと
これがわかりやすいかもしれません、。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd
「図2.4 ネットワークサービスへのアクセス制御」にあるように、まずはTCP Wrapperで仕分けたのちに ”さらに” xinetdで管理するサービスごとの設定を確認して（２段階目の）アクセス制御を行うという感じですかね。
こっちのドキュメントにも書いてありますね。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-xinetd
クライアントが xinetd が制御するネットワークサービスへの接続を試みると、スーパーサービスはリクエストを受け取り、TCP Wrappers アクセス制御ルールを確認します。
アクセスが許可されると、xinetd は、そのサービスの独自のアクセスルールで接続が許可されていることを確認します。
確かに設問の通りであればおかしいですね。
ネットワークIPアドレスが192.168.10.0、サブネットマスクが255.255.128.0のとき、IPアドレスをCIDRで表記したもの
192.168.10.0をネットワークアドレスとする255.255.128.0なサブネットって存在しないですもんね。/25（255.255.255.128）ならあり得ますが。
単に「ネットワークIPアドレス」が「IPアドレス」の誤記かもしれませんが、その辺はPing-tさんの確認待ちですかね。
もう終わってるっぽいですが。
SSH接続できる環境でやってみましたが、 usermod -L するとまずそもそもログインできませんでした。
$ ssh testuser@192.168.64.2
testuser@192.168.64.2's password:
Permission denied, please try again.
testuser@192.168.64.2's password:
Permission denied, please try again.
testuser@192.168.64.2's password:
testuser@192.168.64.2: Permission denied (publickey,password).
で、正解となっている usermod -s /bin/false だと、アカウントは生きているもののシェルが利用できないので対話的ログインできず、すぐに追い出されます。
$ ssh testuser@192.168.64.2
testuser@192.168.64.2's password:
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-26-generic aarch64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Wed Apr 10 16:08:19 2024 from 192.168.64.1
Connection to 192.168.64.2 closed.
この設問で求められているのは「対話的ログインの禁止」であって「アカウントのロック」ではないのはすでに他の方も言及されている通りです。その上であえていうなら
アカウントがロックされたら対話的ログインもできなくなるから
正解だと思ったのですが、違うのでしょうか。
と疑問に思われている通り「求められていることを達成せず別の操作の副次的な影響で達成（したように）するのをよしとするのか」というところでしょうけど、たとえば「 systemctl stop sshd したらリモートから対話的ログインできなくなるからこれもOK」とか「 passwd hoge2 してパスワード勝手に変えたらログインできなくなるのだからこれもOK」とはならないですよね。
この問題では「最も適切なコマンド」を「2つ」選ぶようになっているので、まずは「求められているもの」を主に考えて、あとは試験テクニック的にも「回答数に合う【より適切な】選択肢を選ぶ」というのが優先かなと思います。その上で、求められているものを達成できるものが回答数に満たない場合は次善の選択肢を検討する、という順番がより良いかと思います。
参考の「プライベートアドレスは以下の範囲内で自由に割り当てることができます（RFC 1918で規定）」の下の表を見るとわかりますが、 172.17.33.55 はクラスBプライベートアドレスの範囲に含まれるからですね。
そうですね。設問は
次のログインに関する設定について正しい記述はどれか。
なので、SSHの設定のような「ログインに関する設定以外」は「省略」の範囲に含まれていると考えるのが妥当かと思います。
設問からは
同社はデータセンターの自然災害時の影響を考慮して、AWSを利用した災害復旧（DR：Disaster Recovery）を計画している。
のですから、仮にデータ同期やオンプレミスのシステム停止時切り替えのためにDirectConnectで接続していたとしても、そもそもデータセンターが自然災害により使用不可能な（DirectConnectエンドポイントが機能しない）状態を想定しているので
障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。
だと、「どこのエンドポイントからAWSのバックアップ環境にDirectConnect接続するの？」って観点が不足しているのではないかなと思います。
DNSに関する用語は定義がはっきりしていなかったりするので曖昧に表現すると齟齬が発生する元なので難しいところです。
ここでいう「ホスト名」は「（完全修飾）ドメイン名」の意味で使われていると思われます。逆に、I-chan0234さんがいう「ドメイン名」が完全修飾ドメイン名（FQDN）を意図しているのであれば同一視しても良いと思います。
まぁ問題的には「IPアドレスではなく、名前」というぐらいの意味で理解しても間違いではなさそうです。
本来NICから送信可能な最大サイズを超えたデータが検出されたという意味ですが、そんなの送ってくる時点で送出側のNICが上限以内に収めることができない（正しく動作できてない）と考えられるからですね。
https://www.cisco.com/c/ja_jp/support/docs/switches/catalyst-6500-series-switches/12027-53.html#toc-hId--939937013
ジャイアント フレームとは、イーサネットの最大フレーム サイズを上回る（1518 バイト以上）、不正な FCS を持つフレームのことです。
解説のこの部分についてはcopilotは何か言っていましたか？
また下図の通り、インターフェース（GigabitEthernet0/0）の帯域幅は「bandwidth 100000」によって「100000Kbps」へ変更されています。
うーん…なんか表現の問題な気がしますが
ソリューションアーキテクトは複数のEC2インスタンスで動作するサーバーのストレージについて検討している。
これ、「サーバー」じゃなくて「サービス」とかなら意味がわかるんですよねぇ。
割と「サーバー ＝ EC2インスタンス」な関係だと思うので、Kurojunさんのおっしゃる通り「1つのストレージで複数のインスタンスにアタッチできるもの」という条件にもよめます。でも次の
サーバーのデータは複数のEC2インスタンスにコピーして保存し、データ損失に耐えられるようにする。
からすると「データは複数のインスタンスにコピーされ（複製がある状態にして）データ損失に耐えられる」ためには「1つのストレージ」だと達成できないのですよね。なので「マルチアタッチ」も不適切かなと。
そういうことからすると単純にIOPSだけ見てインスタンスストアってのは導ける気もしますが、なんかうーんって感じますね…
自分の読解力の問題ですみません。質問の内容がよく理解できませんでしたが、こういう検証をしたいがうまくいかないので質問したという意図で良いのでしょうか？
・動的inodeのファイルシステム（例：Btrfs）の準備
# dd if=/dev/zero of=/tmp/btrfs.img bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 2.65423 s, 395 MB/s
# mkfs.btrfs /tmp/btrfs.img
btrfs-progs v5.16.2
See http://btrfs.wiki.kernel.org for more information.
NOTE: several default settings have changed in version 5.15, please make sure
this does not affect your deployments:
- DUP for metadata (-m dup)
- enabled no-holes (-O no-holes)
- enabled free-space-tree (-R free-space-tree)
Label: (null)
UUID: d8471c85-31fe-4aa8-b94c-83c30de9637a
Node size: 16384
Sector size: 4096
Filesystem size: 1000.00MiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 50.00MiB
System: DUP 8.00MiB
SSD detected: no
Zoned device: no
Incompat features: extref, skinny-metadata, no-holes
Runtime features: free-space-tree
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 1000.00MiB /tmp/btrfs.img
# mount -t btrfs /tmp/btrfs.img /mnt
# mount | grep /mnt
/tmp/btrfs.img on /mnt type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop2 1024000 3616 904192 1% /mnt
・何か元になるファイルを用意する（今回はカーネルイメージ）
# cp /boot/vmlinuz /mnt
# ls /mnt
vmlinuz
# ls -l /mnt
total 11364
-rw------- 1 root root 11634760 Mar 20 14:25 vmlinuz
・ファイルシステムの空き容量を確認する（今回は892828）
# sync
# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop2 1024000 14980 892828 2% /mnt
・ハードリンクを作ってみる（今回はコピーしたカーネルイメージを hardlink というファイルにリンク）
# ln /mnt/vmlinuz /mnt/hardlink
# ls -l /mnt
total 22728
-rw------- 2 root root 11634760 Mar 20 14:25 hardlink
-rw------- 2 root root 11634760 Mar 20 14:25 vmlinuz
・ファイルシステムの空き容量に変化があるか確認する（変化なく892828のまま）
# sync
# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop2 1024000 14980 892828 2% /mnt
・ハードリンクが同じinodeを使用しているかを確認する（どちらも 257）
# stat /mnt/vmlinuz
File: /mnt/vmlinuz
Size: 11634760 Blocks: 22728 IO Block: 4096 regular file
Device: 2eh/46d Inode: 257 Links: 2
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-03-20 14:25:41.540446902 +0900
Modify: 2024-03-20 14:25:41.556447169 +0900
Change: 2024-03-20 14:26:58.613713062 +0900
Birth: 2024-03-20 14:25:41.540446902 +0900
# stat /mnt/hardlink
File: /mnt/hardlink
Size: 11634760 Blocks: 22728 IO Block: 4096 regular file
Device: 2eh/46d Inode: 257 Links: 2
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-03-20 14:25:41.540446902 +0900
Modify: 2024-03-20 14:25:41.556447169 +0900
Change: 2024-03-20 14:26:58.613713062 +0900
Birth: 2024-03-20 14:25:41.540446902 +0900