miki_yさんの助け合いフォーラム投稿一覧

本文の解説の以下抜粋部分について、

・localmembers（192.168.10.0/24に属しているクライアント）からのOK_port（80,443）でのアクセスを許可（この条件は2つacl名が並んでいるため、AND条件となっています。）
・OK_port（ポート番号が80,443）以外へのアクセスを禁止
・CONNECTメソッド（プロキシにトンネリング通信を要求するメソッド）を使った通信をSSL（443）以外禁止
・clients（ドメイン名がtest.com）からのアクセスを許可
・eigyobi（月曜日から金曜日の9:00から18:00）の間アクセスを許可

確かに、http_access設定の3行目「http_access deny CONNECT !SSL」は
「CONNECTメソッド（プロキシにトンネリング通信を要求するメソッド）を使った通信をSSL（443）以外禁止」しているのは理解できます。

これに対し、http_accessの2行目は「http_access deny !OK_port(80,443)」ですが、
ポート80 は 3行目の方で拒否される運命なので、2行目はどちらかといえば「http_access deny !SSL(443)」のほうが
適切だと考えましたがいかがでしょうか。

もっと言えば、3行目でポート443以外の利用はどうせ拒否されるので、2行目そのものが不要ということはないですか？

2行目の意義は、想定外のマッチをさせないため(念の為)や、制御の意図を明確にするため、あるいは、
より単純な条件でふるい落としておくことで処理の負荷を下げる、などの理由ですかね。

問題文は「Webサーバの設定で、DNSの逆引きを止める」には、とあります。

HostnameLooksupは、あくまでApacheがログファイル記録上での逆引きの有無の設定で、
Apacheが他の機能のためにDNS逆引きをおこなうことはないのでしょうか。

問題文は Apacheにとってまるで全体的な(汎用的な？)逆引きの有無設定があってそれを問うているかのような文章になっていますが、
回答に対して見るとちょっと聞き方が雑すぎると思ったのは私だけでしょうか。

ApacheがDNS逆引きをおこなうのは実際上はログ記録の場面しかなくて、
これが負荷の上でも問題になるため同ディレクティブでoffとする、というのがApacheを使う上でお決まりの設定となっていて、
だからApacheにおいて「DNSの逆引きを止める」と言われたら普通はこのディレクティブによる設定のことを指すのが
共通認識ということ？

本文の正誤とは関係ないですが、
問題文の設定例で以下２行はそもそもoptionsステートメントの中に入れなくても問題ないのでしょうか？
　allow-query { lan; };
　allow-transfer { lan; };
これらはoptionsステートメントのオプションなのでは。

ありがとうございます。

本問解説の以下２行について。
「ufw default」コマンドで各方向（着信、発信、転送）のデフォルトポリシーを変更します。
「ufw reset」コマンドでこのデフォルトポリシーの状態に戻します。

ufw defaultは、
　①ポリシーのデフォルト値そのものを変えてしまう
　②デフォルトは変わることはないが現在のポリシーをデフォルトから変える
のかどちらでしょうか。解説を素直に読むと①でしょうか。

①の場合、ufw resetは、ufw defaultで変える前の標準のデフォルトに戻るのではなく、
①で変えた後のデフォルトに戻ることになりますか？

それとも、②が正しくて、ufw resetはufw defaultで変える前の標準のデフォルトに戻るのでしょうか。

本文の解説で以下の意味がやや分かりません。

「例えば、LDIFファイルからエントリを追加する際、既に存在しているエントリがあると、コマンドは存在しないエントリを追加することなく
　エラーで終了します。
「-c」オプションを使用することで、LDIFファイルを変更することなく、まだ存在しないエントリを追加することが出来ます。」

普通の感覚で考えると、エラーで終了するのは、すでに存在しているエントリと重複するエントリを追加しようとした時であって、
別に重複しない完全に既存のどのエントリとも別の新しいエントリを追加するだけならエラーは出ない、
と思ったのですが、認識違いますか？
「コマンドは存在しないエントリを追加することなくエラーで終了します。」という書き方が引っかかりました。
つまり、既に何かエントリが存在しているというだけで、それらと何も重複しない、つまり、「存在しないエントリ」であっても
新しくエントリを追加しようとするととにかくエラーが出てしまうかのように読めてしまいました。

＞OpenLDAPにおいて、アクセス制御の設定を何も記述しない場合は「access to * by * read」と同じ条件が適用され、
=>「olcAccess to * by * read」の誤記？

＞また、これと同じ意味をもつものが以下の設定です。
＞　olcAccess: access to *
＞　 by anonymous read
＞　 by * none
=> 2行目のaccessは不要？

ping-t 事務局各位

コマ問の問題にて
　virshコマンドのサブコマンドで、仮想マシンに割り当てる仮想CPU数を指定するものは？

virsh -> virt-install の間違い。修正してください。

※コマ問にも問題IDを付けるべきでは。

問題ID 21930ではxfsは「標準的」に使われては"いない"との解説であった。

事実そうだと思いますが、
一方で本問題21803ではxfsは「汎用的」に使用されるファイルシステムに該当するとのことですが、
ここで言う汎用的とは？「広く使われる」という意味では、違うような。。。

ありがとうございます。

Zabbixも
「サーバの死活監視や、ネットワークサービスの状態やリソースの使用状況などを統合的に監視するツール」で、
「プラグインを追加して監視する項目を増やせたり、ユーザが独自のプラグインを開発できる」と思うのですが
(Zabbixプラグインについて参考：https://www.zabbix.com/documentation/6.0/jp/manual/config/items/plugins)
Zabbixが不正解の理由を知りたいです。

※解説の、Zabbixが不正解である説明が雑すぎる。
「死活監視や、ネットワークサービスの状態やリソースの使用状況、クラウドなどを統合的に監視するツール」って、
説明になって無い気が。ping-t が作っているツールの概要説明をただ書いただけで、問題文の特徴がなぜ該当しないのかの
説明をちゃんとしてほしいのだが。ping-tの解説はこういうのが多い気がする。

解説がよくわかりませんでした。

①iwconfig wlan0 essid "pubcafe" は、
以後wlan0を使ってなにかをする際にアクセスポイントpubcafeを使うよう事前設定するためのコマンドで、
実際に接続をするわけではなくて、
一方で
②iw dev wlan0 connect pubcafe は、
実際にインターフェースとアクセスポイントを指定して接続を実施する

という違いがあると解釈しました。
さらに、②はわざわざアクセスポイントを明示的に指定して接続するのだから、
事前に①を実施しておく必要があるわけではないのではないですか？

これらの解釈が合っているならば、ですが、この問題の回答は本当に①と②をどちらも選ぶのが正解なのか疑問を覚えました。
もし、(接続はせずに)設定を行うだけだったら①だけでよいはずで、②だと接続までしてしまいます。
また、問題の意図が、実際に接続することまでを含むのだとしても(だとすると問題文がおかしい気がしますが)、それであれば、
②を実施して接続する前に①を実施したか否かは無関係なのだから回答は②だけなのでは？

また、もし仮に②の接続の事前準備に①が必要だとするならば、①で使うアクセスポイントをあらかじめ指定しているにもかかわらず、
②で接続する際にまたいちいちアクセスポイントを指定しなければならないのもおかしい気がします。

以上をふまえ、この問題の意図が、回答である①②の関係性の点で、解説からは理解できませんでした。

問題文は
　　OSSを他のソースコードと組み合わせて再配布する場合、他のソースコードの公開を求めないライセンスはどれか
回答にはLGPLが該当するとのことですが、問題文の"組み合わせて"の定義が少し疑問です。
解説の表だけを見ると確かにLGPLは該当するように見えます。

ですが、LGPLは、そのLGPLライブラリを動的リンクする分にはLGPLは適用不要(利用元のソースコードの開示は不要)ですが
静的リンクでソースコードとして組み込んだらLGPLは適用されソースコードの開示が必要になりますよね。
現に、本問解説の後の参考の説明にも「LGPLのバイナリを動的リンクとして呼び出すソフトウェアにはLGPLの権利は及びません。
LGPLのコードをソフトウェアに組み込んだ場合は、LGPLが適用され、ソースコードの開示が必要となります。」とあります。

改めて問題文には「OSSを他のソースコードと組み合わせて再配布する場合」とあります。
LGPLは上記のとおり動的リンクと静的リンクでソースコード公開要否が変わってくるはずで
この問題文は「"ソースコードと"組み合わせて」とあるのでLGPLでもどちらかといえば静的リンクの方を指しているような書き方です。
にもかかわらず、どうして動的リンクの方の側面が採用されLGPLが該当するとされているのかがよく分かりません。

15004の回答で「ハードリンクはディスク容量を消費しない」が正解とされてますが
ハードリンクを作成した際にはディスク中の固定サイズ領域であるinodeテーブルに情報が
追加(=容量を消費)されていくのであって通常のファイル保存に使う領域が消費されることはない、という理解であってますか？

もしそうだとすると、動的inodeのファイルシステムではその限りではなくなりそうなので
通常のファイル保存に使う領域は、実質inodeのために動的確保された領域のために消費され(または容量の取り分が減らされ)て
しまうのではないですか？
あるいは、動的といっても規定サイズの領域の範囲内で可能な数までは動的生成が可能ということでしょうか？