arashi1977さんの助け合いフォーラム投稿一覧
作成時は「どのテーブルに紐づくインデックスか」を指定する必要があるのに対して、削除、変更時は「どのインデックスに対しての操作か」と言う指定になるので、紐づくテーブルの情報は不要ってだけだと思いますよ。
関連するテーブルが異なる同名のインデックスが作れるなら話は違いますが。
https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst1000/software/releases/15_2_7_e/command_reference/b_1527e_1000_cr/interface_and_hardware_commands.html#wp3785065436 をみると、この出力は「プルーニングに適格な VLAN を一覧表示します。」とあるので、「Pruning対象となるVLAN」のはずです。
「vtp pruning
が有効になっている環境であれば、 VLAN :2-1001 がプルーニングの対象となる(拡張VLANは対象外)」ということを意味しているだけかと思いますよ。
kvm コマンドは、Debian系のものなのに、centos.img とRedHat系のものが使われているのが
矛盾しているような気がします。
特に矛盾しないんですね。
kvmコマンドは「KVMを操作する」コマンドなので、Debian そのもの ではないです。
そして、centos.imgは「仮想マシンのイメージファイル」なので、ホストOS(ハイパーバイザ)が何であるかは関係ありません。
別の話で言えば、「Windows上のVMware PlayerでUbuntuが動く!?VMware PlayerはWindowsのアプリなのに、実行させる仮想マシンがLinuxなのは矛盾しているのでは?」という話と同じことです。
解説の
次に、QEMUモニタで参照したときのブロックデバイスの表記と、qemu-kvmコマンドのオプションとの対応を以下に示します:
の対応からは -cdrom
がセットされた場合のブロックデバイスは
ide1-hd0/ide1-cd0 : -hdc, -drive index=2,-cdrom
とあるので、 ide1-cd0
だと導けるのだと思いますよ。
これらは「* FROM」「;」の有無が異なるのですが、
意味は同じと考えてよろしいでしょうか。
そうですね、公式ドキュメントからもそう読めます。
https://www.postgresql.jp/document/13/html/sql-select.html
FROM句
(略)
function_name
FROM句では、関数呼び出しを使用することができます (これは特に関数が結果セットを返す場合に有用ですが、任意の関数を使用することもできます)。 SELECTコマンドの実行中は、この関数の結果は一時テーブルであるかのように動作します。 関数呼び出しにWITH ORDINALITY句を追加した時は、すべての関数の出力列の後に各行の番号の列が追加されます。
それと最下部あたりの「FROM内の関数呼び出し」とかですかね。
実際に実行しても、結果としては同じになります。
% kubectl run postgres --image=postgres --env=POSTGRES_PASSWORD=postgres --env=POSTGRES_USER=postgres
pod/postgres created
% kubectl exec postgres -it -- psql -U postgres
psql (14.3 (Debian 14.3-1.pgdg110+1))
Type "help" for help.
postgres=# select * from current_user;
current_user
--------------
postgres
(1 row)
postgres=# select current_user;
current_user
--------------
postgres
(1 row)
さて、問題ID:12180そのものに関する質問ではないのでどうコメントするか悩ましいところですが。
とりあえずやってみたらいいんじゃないですか?
CREATE DOMAIN original_type AS integer DEFAULT 10
CREATE TABLE test(id original_type DEFAULT 5 ....
手元にdockerイメージでPostgreSQL環境作って投げてみましたけど、gzx01277さんのSQLはそのまま通ったっぽいですよ。
(dockerじゃなくkubernetesでやってるのでコマンドラインとかちょっと違いますけど本質はそこではないので)
% kubectl run postgres --image=postgres --env=POSTGRES_PASSWORD=postgres --env=POSTGRES_USER=postgres
pod/postgres created
% kubectl exec postgres -it -- psql -U postgres
psql (14.3 (Debian 14.3-1.pgdg110+1))
Type "help" for help.
postgres=# CREATE DOMAIN original_type AS integer DEFAULT 10;
CREATE DOMAIN
postgres=# create table test (id original_type DEFAULT 5);
CREATE TABLE
postgres=# \dt
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | test | table | postgres
(1 row)
postgres=# \d test
Table "public.test"
Column | Type | Collation | Nullable | Default
--------+---------------+-----------+----------+---------
id | original_type | | | 5
postgres=# \dD
List of domains
Schema | Name | Type | Collation | Nullable | Default | Check
--------+---------------+---------+-----------+----------+---------+-------
public | original_type | integer | | | 10 |
(1 row)
postgres=#
もし併用が可能ならば、デフォルト設定のルール(例:ドメイン作成の方が優先、
最新の設定や変更で上書き)を教えてください。
そう言った話は、公式ドキュメントをもとに調べてみたりネットで検証してる人の記事なりを探してみてはどうでしょうか?
もしくはご自身で検証して、その情報を公開されると同様の疑問を持つ方への良い貢献になると思いますよ!
問題内容のlocalはlineではないのでしょうか。
逆質問になってしまうのですが、なぜlineだと思ったのでしょうか?
もし違っていたら、理由を教えてほしいです。
設問の通りであれば、「ローカルデータベースによる認証を行う」に該当するのがlocal
メソッドなので、これがないと正答選択肢の通りにならない、ということかと思います。
実機確認はしてませんが、動きとしてはこうなるはずです。
- PC1→PC4:SwitchAはFa0/1で受け取ったフレームをVLAN10と理解し、Fa0/24から「VLAN10のタグ付き」でフレームを送出。SwitchBは「VLAN10のタグ」を元にFa0/1へフレームを転送
- PC4→PC1:SwitchBはFa0/1で受け取ったフレームをVLAN10と理解し、Fa0/24から「タグなし」でフレームを送出。SwitchAは「タグなしフレーム」なので、native VLAN設定に基づきVLAN20に属するFa0/2へフレームを転送
参考の以下の部分が関連するかなと思います。
IEEE 802.1Qでは通常、フレームにタグを付けて送信しますがネイティブVLANにはタグを付けません。そのため、受信したフレームにタグが付いていない場合はネイティブVLANと判断できます。
この場合 192.168.0.1/24 への経路を RA は把握しているのでしょうか。
設問の出力だけで言えば、把握していると言えますね。というのもRAでtracerouteを打った結果、経路を把握していない場合は以下のような出力になるからです。
RA#traceroute 192.168.1.6
Type escape sequence to abort.
Tracing the route to 192.168.1.6
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
こうではなく、172.16.1.2→172.16.11.4→172.16.11.3…と回っていることから、RAは192.168.1.6へのネクストホップを172.16.1.2であると学習していると言えます。この辺りはCCNAのレベルでも学習するはずなので、ルーティングなどについて復習されると良いかなと思います。
問題文、解答は下記の通りだが、問題文に10.0.2.101”から”とあるにもかかわらず、dstが正解扱いになっているのは誤りだと感じた。
誤りだと「感じた」のは主観のお話なので実際は解説の実行例の通り正解は変わらないのですが、最終的には日本語難しい的なお話なのかなと思いました。
問題文は
ホスト10.0.2.101から他ホストに対してpingを打ち続けている時のパケットを監視したい。tcpdumpコマンドの下線部に入れられるキーワードはどれか。(3つ選択)
となっています。で、sakagihogeさんの認識は
echo応答が返るといっても、パケットの向きは他ホストからホスト10.0.2.101になるので、「ホスト10.0.2.101から他ホストに対して」という表現と逆になってしまうと考えます。
です。ですがこれは切り取る場所が不自然かなと思います。
設問は【「ホスト10.0.2.101から他ホストに対してpingを打ち続けている」時の「パケットを監視」したい】のであって、【「ホスト10.0.2.101から他ホストに対して(片方向)」の「パケットを監視」する】とはなっていないですよね?
そうするとここでは「pingを打ち続けている時のパケット」を監視するのですから、pingの通信(通信というのは不自然な気がしますが)を構成する「送信元から宛先へのecho request」と「宛先から送信元へのecho reply(もしくは途中のホストから送信元へのDestination Unreachable/Time Exceededメッセージなど)」を対象にするのは問題ないと言えると思いますが、どうでしょうか?
解説に、「(department_id = 3 OR salary > 400000)」の部分が先に評価され
とあるので、department_idが3であるD,Eもしくはsalaryが400000より大きいA,D,Eが回答の選択肢に入ると私は考えます
まず解説の2行目をみてみます。
AND演算子とOR演算子ではAND演算子のほうが先に評価されますが、()括弧がある場合は、括弧内の演算子を優先して評価します。
これからすると、「かっこ→AND→OR」の順に評価されると読めます。その前提で解説の最後の文を再確認しましょう。
設問では「(department_id = 3 OR salary > 400000)」の部分が先に評価され、次にANDですので、「DEPARTMENT_ID列が3かSALARY列が400000より大きく、かつ COMMISSION列が1200000以下である」列(E)、または、「HIREDATE列が2008年4月1日より大きい(新しい)」列(B,C)が検索されます。
カッコだけの評価ならsushitaroさんの言われる通りかもしれませんが、その次にあるANDが抜けているのでずれているんですよね。
順番としては「(department_idとsalaryの条件) かつ commissionの条件」というひとまとまりがあり、次にORで繋がった「hiredateの条件」がくるのですよね。
算数的に考えると
(A + B) x C + D
で「A + B」だけで終わりにして、Cをかけるのを後回しにして C + D をやろうとしてる感覚です。
sqlite3で実験してみましたが、条件をいじるとこんな感じで結果が変わってきます。
sqlite> SELECT *
...> FROM employees
...> WHERE (department_id = 3
...> OR salary > 400000) ;
5|500000|2000000|01-10-01 ←A
3|500000|2000000|01-10-01 ←D
3|400000|1200000|02-12-01 ←E
sqlite> SELECT department_id, salary, commission, hiredate
...> FROM employees
...> WHERE (department_id = 3
...> OR salary > 400000)
...> AND commission <= 1200000;
3|400000|1200000|02-12-01 ←Eだけになっているので、ANDが効いていることがわかる
sqlite> SELECT *
...> FROM employees
...> WHERE (department_id = 3
...> OR salary > 400000)
...> AND commission <= 1200000
...> OR hiredate > '08-04-01';
1|350000|800000|11-04-01 ←B
4|200000|800000|10-04-01 ←C
3|400000|1200000|02-12-01
↑ hiredateの条件でヒットしたB, Cが抽出されている
もう解決されてると思いますが。
これは各ルータ自身の中では一致させる必要があるのでしょうか。
いくつかの設定コマンドでrouter ospf [プロセスID]に入って設定するコマンドがありました。
そういったときに、同じルーターにrouter ospf [プロセスID]に入って設定するコマンドの場合、プロセスIDは統一させないといけないのでしょうか。
OSPF(に限らずEIGRPとかRIPとかでも)のプロセスというのは「ルータ内部での管理範囲」みたいなものです。
例としては変かもしれませんが、Excelファイルを複数開いてたとして、Aというファイルに対する編集はBには関係ないですよね?それと同じことで、「OSPFプロセスID:1に属しているインターフェース、ルーティング情報」は「OSPFプロセスID:2」とは別物になるのです。
それの何が嬉しいの?って話ですが、これはかなりの大規模じゃないとあまりメリットはないかな…CCNPのVRFとかと関連づけると嬉しさがわかってくるかもしれません。
選択肢では(一旦exitしているとはいえ)IPアドレスを設定し直しているように見えます。
し直してますね。そうするとこんな感じのことが起きるのです。
Router#show vrf ←VRF未設定
Router#sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/1 unassigned YES unset administratively down down
GigabitEthernet0/2 unassigned YES unset administratively down down
GigabitEthernet0/3 unassigned YES unset administratively down down
Router#conf t
Router(config)#vrf definition VRF_A
Router(config-vrf)#int g0/0
Router(config-if)#ip addr 192.168.1.1 255.255.255.0
Router(config-if)#do sh ip int br g0/0
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.1.1 YES manual administratively down down ←アドレス割り当てできている
Router(config-if)#vrf forwarding VRF_A
% Interface GigabitEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF VRF_A ←VRF関連付けをしたのでIPアドレス設定が消される
Router(config-if)#do sh ip int br g0/0
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES manual administratively down down ←消えている
Router(config-if)#
つまり、「一旦exitしているか」は特に影響なく、 vrf forwarding VRF名
というコマンドの 後に IPアドレス設定をしていなかったらだめ、というだけの話なのです。