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

助け合いフォーラムの投稿
2024/04/12 コメント
LGPLのソフトウェア公開義務について
こちらこそ、ありがとうございます。 以下、自分の中で勝手に納得した自分なりの方針ですが、 この問題の解説の後にかかれている「参考」で、大まかな観点別に表で分類されている部分と、個別のライセンスの特徴を詳細に説明している部分がありますが、 出題のされ方として、もし後者の個別の特徴の理解を問う問題であれば、もう少し問題文も具体的にそのライセンスと特定しやすい説明が並ぶ気がします。本問題のように大雑把な特徴だけが書かれているのであれば、細かい個性は置いといて難しく考えすぎず大まかな分類上当てはまるライセンスを選んでおけばよいのかな、と。いったんそれで納得するようにしました。 普段からLv1でマニアックな理解など問われないのでもっと大雑把に考えてよいとは思っていても、この問題みたいに解説にもLGPLについて詳しく書かれていて解釈に戸惑うことは多々あります。逆に、大雑把でよいと思いきや、意外と問題文を厳密に捉えないとミスリードされるような問題もあったりで。 結局youmiさんが最初に助言してくださったように、割り切ってしまうしかないんですね。
2024/04/11 コメント
usermod -L は対話的ログインは禁止されないのか
ありがとうございます。 以上総合し、また解説にも対話的ログインを禁止する直接的な方法ではない、と書かれていることから、問題文の言い回しというか解釈が絡むのですね。 「対話的ログインを禁止する方法を選べ」であればコマンドの主目的(主作用)として考える必要があって、 「次のコマンドのうち対話的ログインが禁止されるものは?」であればそのコマンドの主作用でなくても複数の作用があっても問題文の作用が入っていれば答えに該当するものと思えばよさそうですかね。 普通に読めばそうだろうと言われればそれまでですが、ほかにもこういう言い回しでどう捉えるべきか引っ掛かりそうな問題がしばしばありますね。 変なひっかけではなくちゃんとした技術的理解度を問うてほしいと思いつつ、 本チャンのLinuCの問題もこういう感じなのであれば、割り切りたいと思います。 いろいろご助力いただき大変感謝です。ありがとうございます。
2024/04/10 コメント
LGPLのソフトウェア公開義務について
ありがとうございます。 記載いただいた点もふまえ、 ひとまずこのような問題はLGPLが準コピーレフトに分類されている視点で、 個別の個性は無視して準コピーレフトとしての共通項として答えておくのが無難 と考えるしかないかもしれません。
2024/04/09 コメント
LGPLのソフトウェア公開義務について
ありがとうございます。 日本語の解釈がどうとかいうのは、質問のためにそういう書き方をしてしまいましたが、要は、LGPLはソースコードの公開が必要な場合もあるにも関わらずLGPLが正解の1つになっているのがおかしいのではないか、という単純な問いかけです。 難問や悪問が混じっていても完璧を目指さず確実に取れる問題だけ相手にして要領よく点を取って時短で合格しよう、というのは、まああるのですが、 テクニックだけを突き詰めれば究極こんなフォーラムも、動作確認するための仮想環境も何も必要なくなります。 ただの点取りではなく実用も考慮して正しい理解もしておきたいからこそ フォーラムの活用や実環境での動作確認にもある程度は時間を使いながら 進めているので。 そもそも、仮にテクニック偏重で機械的で丸暗記する立場で捉えたとしても、こういう問題のために誤った暗記をして実際のLinucで間違うのもつまらない話なので。
2024/04/07 投稿
LGPLのソフトウェア公開義務について

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

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

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

2024/04/03 コメント
動的inodeのファイルシステムでもハードリンク作成はディスク容量を消費しないのか?
私の代わりにいろいろ実験までしていただき感謝です。 たしかに、割り切ってシンプルに考えておくことにしたいと思います。 ありがとうございました。
2024/03/30 コメント
動的inodeのファイルシステムでもハードリンク作成はディスク容量を消費しないのか?
ありがとうございます。 うまく説明できずすみません。 例えば、あるfile.txtに対するハードリンクを ①~/hoge/linkfile.txtに作ったとします。 同様に②~/piyo/linkfile2.txt にも同じ実体に対するハードリンクを作ったとします。 この場合、両者とも同じ実体を指すとしても、①と②でリンクの置かれるディレクトリ名もファイル名も異なりますし、それら(パスとファイル名)に関する情報は何かしらどこかに持っておかないといけないと思うのです。 もっと極端に、これと同じ実体に対するハードリンクを、全く別々の場所に別々の名前で、さらに100万個作った場合は?、、、と考えていくと、 各リンクのパスに関する情報はどうしたって保持しておく必要があり、いくらなんでも0Byteというわけにはいかないと思うのです。 この理屈でいくと、静的inodeでも動的inodeでも、ハードリンクを何百万個、何千万個作ってもハードディスクの容量が一切消費されないというのはありえないのでは?というのが素朴な疑問となりました。 シンボリックリンクと違いリンクファイルの持つサイズ自体は何個作っても増えるわけではない、と言われると違和感がないのですが、 ハードリンクを何個作っても容量は消費されない、と言われると、上記のように理屈上あり得ないのではないか、と思うのです。 試験対策上は細かいことは考えず容量消費がないと覚えておけばよいと割り切るしかないのは重々分かっていますがどうも引っかかります。
2024/03/24 コメント
動的inodeのファイルシステムでもハードリンク作成はディスク容量を消費しないのか?
ありがとうございます。 いえ、動的inodeのファイルシステムでもハードリンク作成はディスク容量を消費しないといえるのか、またそれはなぜか簡単に理由(しくみ)を教えてほしい、 という意図で質問しました。
2024/03/20 投稿
動的inodeのファイルシステムでもハードリンク作成はディスク容量を消費しないのか?

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

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

2024/03/09 コメント
アカウントのロック、ログインの禁止 方法について
すみませんが、そういうのは分かった上で時短のため投稿していますが。 それと、汗(;)で呆れを表現しなくてもいいですよ? dockerコンテナも仮想マシンも実施環境は持っており、ググって分からず 比較的試しやすいものであれば都度実動作で確認はしています。 とはいえ全てを実物確認していたらキリがないので投稿しています。 「自分でやってみては」は、理想はそうでしょうが、それを言っていたら QAやフォーラムの意味がないかと。 あと、全部把握しているスーパー受験者さんの投稿に期待しているのではなく、 断片的にでも知ってる方の情報がもらえればよいと思っているのと、 どちらかといえば事務局の方向けの発信の意味合いが強いです。 (問題に関するQAは事務局に直接出せないため。事務局の方はすべての投稿に目を通されているとのなので)
2024/03/06 コメント
usermod -L は対話的ログインは禁止されないのか
連投になりますが、ほかのサイトの例ですと https://note.com/goldnanoparticle/n/ncfe49f22a215 ここでは、usermod -L を「対話的」ログインを禁止する方法の例として挙げているように見えますね。 最初にご回答いただいているように、対話的ログインだけでなくその他のことまでできなくなってしまう、という点で不適切ということなのですかね。 それはそれで問題として意地悪すぎますね。 それであれば「対話的ログイン"のみ"を禁止する方法は?」といった書き方にしてほしいところです。実際にping-tの他の問題で、問題文で「のみ」と限定していてそれ以上のことまでできてしまう選択肢をそういう理由で不正解としている問題がありました。
2024/03/05 コメント
usermod -L は対話的ログインは禁止されないのか
2件もご返信いただきありがとうございます。 そうなのですね。あるユーザに対し対話的にログインさせることを禁止させる方法を問うているのではなく対話的ログインという機能自体を禁止させる方法と解釈すべし、ということですかね。 ただ、正解の2つの選択肢の方も、どちらもユーザ名を引数に取っていて、対象のユーザのログインだけを禁止する方法が正解とされているように見えました。 もともと、 複数サイトでみても、「usermod -L ユーザ」の挙動の説明として、だいたい「アカウントのロック」「パスワードのロック」「ログインの禁止」のいずれかの説明となっていて、対話的/非対話的ログインのどちらが(どちらも?)可能なのかがはっきり書かれたサイトが見つけられませんでした。 また、もしusermod -Lでも対話的ログインはできるのだとすると、 https://linuc.org/study/samples/318/ このLPI-Japanのサイトの問題で「既存ユーザのパスワードをロックして一時的に利用不可にする」コマンドの正解が usermod -L となってまして、 一時的に利用不可する手段のわりに、対話的ログインは普通にできてしまうのも違和感がありまして、、 実際に実験してみるのが早いのかもしれませんね。。。
2024/03/03 投稿
usermod -L は対話的ログインは禁止されないのか

対話的ログインを禁止する方法、というこの問題の解説に対し
usermod -L hoge2
は、アカウントがロックされてしまうため不正解とありますが
アカウントがロックされたら対話的ログインもできなくなるから
正解だと思ったのですが、違うのでしょうか。

それとも、アカウントがロックされても普通に対話的ログインできてしまうということでしょうか?
(だったら何のためのアカウントロックなのでしょうか)

他のLinuxやLinucの解説サイトではusermod -L が対話的ログインを禁止する方法として
挙げられていませんか?

2024/03/02 投稿
アカウントのロック、ログインの禁止 方法について

以下、ご教示いただけないでしょうか

・「アカウントを使用させないする方法」「ログインを禁止する方法」がしばしば問題に出ますが、
 これらはイコールではないのでしょうか?

・以下のコマンドは、すべて「対話的な」ログインを禁止するだけでsshログイン等の非対話的ログインは禁止しないという理解でよいでしょうか
  ・passwd -l / usermod -L
  ・usermod -s で ログインシェルを/bin/falseまたは/sbin/nologin に変更

・/etc/passwd や /etc/shadow の該当ユーザのパスワードフィールドの1文字目に「!」または「*」を追加
 する方法は、対話的なログインのみの禁止なのか、非対話的ログインも含めた禁止なのか、どちらになりますか。

・同様に、/etc/nologin を作成する方法(root以外の一般ユーザログイン禁止)は、いかがでしょうか

・対話的/非対話的ログインをどちらも禁止できる方法は何がありますでしょうか

以上を踏まえ、様々な「アカウント使用禁止」「ログイン禁止」コマンドについて、
これらの違いもふまえ、何がどこまで禁止されるのか、対話的/非対話的ログインのどちらが禁止されるのか、
比較一覧できる表が問題の解説文に掲載されると非常に助かります。

戻る