古い防犯カメラの録画データを保存するために、小型のPCを格安で買ってきてストレージ代わりに使うことってありますよね。特に規模の小さい事業場だと、事務用として使えなくなったPCを流用することもあるようです。そういう場合、OpenMediaVaultを入れてsambaサーバーを構築し、ストレージとして活用していました。
今回も同様の手順で作業を進めていたのですが、問題が発生しました。なんと、カメラがsambaの共有フォルダに接続できないのです。アカウント設定を間違えたのか、アクセス権の設定に問題があるのか、原因を特定しようと色々試してみたのですが、結局のところ、カメラが対応しているプロトコルが古すぎたことが原因でした。
そこで、思い切ってsmb設定画面のextra settingに「server min protocol = nt1」という設定を入力してみたところ、問題なく接続できるようになりました。意外と忘れやすい設定なので、ここにメモとして残しておきます。
（gemini に清書してもらったら、なんか微妙に初心者っぽく演出した意識高い系みたいな文章になった。なんだろ、これ）
DistroWatch Weekly, Issue 1065, 8 April 2024 より抜粋
Questions and Answers (by Jesse Smith)（元記事）
先週、我々はxz圧縮ソフトウェアにおける悪用について報告した。この問題は早期に発見され、広まることはありませんでしたが、その深刻さに多くの人々が注目し、疑問を投げかけました。以下に、それらの質問のいくつかを取り上げます。
Auditing-the-source asks: 完全に監査されているディストリビューションはありますか？コードの全行がチェックされるような？
DistroWatch answers: どの Linux ディストリビューションも、一行ごとに完全に監査されているとは思えません。Red Hat Enterprise LinuxやSUSE Linux Enterpriseのように、認証プログラムの一部として、かなり徹底的にチェックされているディストリビューションはあります。そして、Trisquel GNU/Linuxのような、完全に自由(フリーソフトウェア)なディストリビューションもあります。BSDの世界では、OpenBSDのコードは、おそらく、ほとんどのオープンソースプロジェクトよりも 注意深く監視されてきたことでしょう。しかし、本格的なディストリビューションは、何億行ものコードを含んでおり、 継続的に手作業で一行一行監査することは現実的ではありません。
とはいえ、多くの主要なオープンソース・プロジェクトは、新しいコードが提出されたときに査読を行っています。多くのパッケージメンテナーは、新しいバージョンのソフトウェアにどのような新しいコードが含まれているかをチェックしています。Linuxカーネルのような主要なプロジェクトに入るコードは、バグ、脆弱性、後退など、問題を探すために複数の人によってくまなくチェックされるのが一般的です。そのため、コードベース全体が定期的なレビューを受けることはないかもしれないものの、エコシステムに入る変更は通常チェックされます。
Worried-about-more-backdoors asks: Linuxの重要なパッケージには、他にどんなバックドアがあるのだろうと猜疑的になっています。xz問題のような他の問題がある可能性について教えてください。
DistroWatch answers: 覚えておくべきことは、xzの悪用は何年もかけてゆっくりと行われたということです。新しい開発者が既存のプロジェクトを引き継ぎ、作者が将来脆弱になる可能性のあるコードを少しずつ挿入し、そして悪用を開始するためには、多くの調整が必要だった。このような複数年にわたるゆっくりとした作業の後、悪用は2カ月以内に発見され、パッチが適用された。これは、危険なバージョンのxzが固定リリース・ディストリビューションに入る前であり、いくつかのローリングリリース・ディストリビューションに入る前であった。この脆弱性を導入したユーザーはごくわずかで、そのようなユーザーは最先端を行く人たちでした（Arch Linuxユーザー、Debian Unstableをテストしている人たち、Fedora Rawhideユーザー）。ベータテスターやローリングリリースで常にアップデートを行う人以外で、この脆弱性をインストールする危険性がある人はほとんどいませんでした。
この悪用策を練り上げ、アップストリームプロジェクトを操作するためには何年もの作業が必要であり、ほとんどのディストリビューションが悪意のあるバージョンをパッケージ化する前に、この悪用策はすぐに摘発さ れましたから、バックドアを作ろうとする他の（成功した）試みが野放しになっている可能性は低いと言えるでしょう。
Checking-for-viruses asks:Linuxの各種ディストリビューションは、xzバックドアのような問題を防ぐためにアンチウイルスを同梱するようになるのでしょうか？
DistroWatch answers:理由はいくつかありますが、第一に、テストと監査プロセスがバックドアを素早く発見しました。オープンソースの監査プロセスは期待通りに機能したので、別のチェックは必要ないと考えられます。
第二に、アンチウイルスは信頼性が低く（誤検知や実際の問題の見落とし）、多くのリソースを消費する傾向があります。
第三に、アンチウイルスは検索対象を決める必要があります。言い換えれば、（既知の、あるいは疑わしい）問題を検出する訓練が必要です。アンチウィルス・プログラムは、xzのような脆弱性に類する問題を探しださなくてはいけません。そのためには、アンチウイルスを常に最新の状態に保つ必要があります。つまり、ダウンロード元のリポジトリでアンチウイルスを実行するメリットはほとんどありません。
別の言い方をすれば、もしLinuxコミュニティが脆弱性について知っており、アンチウィルスにそれを検出して除去することを教えることができるなら、さっさと悪意のあるパッケージをリポジトリから除去し、良いバージョンに置き換えればよいのです。しかし、もし私たちが悪意のあるパッケージとその振る舞いについて知らなければ、アンチウイルスソフトウェアを訓練できません。
アンチウィルス・スキャナーは、状況によっては役に立つこともありますが、ユーザーが吟味されたリポジトリからプログラムをダウンロードする場合には、あまり高価を発揮しません。アンチウィルス・スキャナーは、信頼できないサードパーティのソースからプログラムをダウンロードしているユーザーにも、ほとんど役に立ちません。
On-the-lookout asks: オープンソースはこのようなものから我々を守るはずじゃなかったんですか？
DistroWatch answers: 私たちがxzについて話しているのは、チェックがうまくいったからです。誰かがxzの問題に気づき、調査し、（関係するすべてのソフトウェアがオープンソースであるおかげで）問題を特定することができました。数日以内に、すべての主要なディストリビューションはこの問題を認識し、エクスプロイトされたバージョンのxzをパッケージ化しないようにするか、リポジトリで置き換えられました。
作成に1年以上かかった今回の問題は、主要なディストリビューションのリリースに入る前、固定リリースのディストリビューションに入る前、そしてエクスプロイトが機能しそうなディストリビューションにインストールされる前に発見され、対策された。(xzエクスプロイトは、ディストリビューションがxzバージョン5.6以降、OpenSSHサーバー、systemdを実行している必要がありました)。OpenSSHサービスを実行しているopenSUSE Tumbleweedユーザ以外では、影響を受ける人はほとんどいないでしょう。
簡単に言えば、関係するコンポーネントのオープンソースの性質と、実施されたテストプロセスが功を奏したということです。xzエクスプロイトは、xzプロジェクトを危険にさらし、エクスプロイトを導入するために何カ月も費やしたにもかかわらず、Linuxコミュニティにはほとんど影響を与えなかった。これは、オープンソースの実践が失敗したという事例ではなく、オープンソースのテストと監査が非常にうまく機能しているという輝かしい例なの です。完璧ではないが、非常にうまくいっていることを示しています。あなたがベータ・テスターでない限り、あなたのコンピューターにxzエクスプロイトがインストールされたことはないでしょうから、あなたは守られていたといって良いでしょう。
DistroWatch Weekly, Issue 1064, 1 April 2024 から抜粋
Questions and Answers (by Jesse Smith)（元記事）
The-thundering-herd asks: GNU Hurdの現在の状況は? まだ開発中ですか?
DistroWatch answers: このプロジェクトに馴染みのない人々にとって、HurdはGNUのマイクロカーネル・プロジェクトの名前だと思われます： 「GNU HurdはGNUプロジェクトのUnixカーネルの代替です。Machマイクロカーネル上で動作し、ファイルシステム、ネットワークプロトコル、ファイルアクセス制御、およびUnixカーネルや類似のカーネル（Linuxなど）で実装されているその他の機能を実装するサーバーの集合体です。"
Hurdは現在も開発中であり、プロジェクトはカーネルの新開発に焦点を当てた最新情報を不定期に発表しています。
まだ開発中ではあるが、HurdカーネルはLinuxやFreeBSDカーネル、あるいはHaikuのカーネルのように勢いを増すことは一度もなかった。Hurdカーネルはハードウェアを十分にサポートしておらず、CPUアーキテクチャのサポートも限定的です。ほとんどのハードウェアで動作する可能性は低く、主要なオペレーティング・システムとして使用できるほど安定していません。
Hurdカーネルを使用する数少ないオペレーティングシステムの1つは、GNU HurdとGNUユーザーランドユーティリティおよび軽量デスクトップ環境を組み合わせたDebianプロジェクトの移植版です。DebianのGNU Hurd移植版は、いくつかの仮想マシンで動作し、DebianのメインLinuxブランチと同じオープンソースソフトウェアアプリケーションの多くを実行することができます。
過去に、LXDE デスクトップと Debian のソフトウェアリポジトリのサブセットを実行するときに Debian の Hurd ブランチを実行するのがどんな感じかについて触れました。（訳注： Issue 620 参照）
proxmox 上のコンテナに gitbucket をインストールした時のメモ
apt update apt upgradeでシステムを更新したあとで、
apt install openjdk-17-jdkで OpenJDK 17 を導入(JREも導入されます）
wget https://github.com/gitbucket/gitbucket/releases/download/4.40.0/gitbucket.warで gitbucket を引っ張ってきて、/usr/local/bin に移動
[Unit] Description = gitbucket daemon [Service] ExecStart = /usr/bin/java -jar /usr/local/bin/gitbucket.war Restart = always Type = simple [Install] WantedBy = multi-user.target
systemctl start gitbucket.serviceとくにオプション付けてなかったら、localhost:8080 でつながる
systemctl status gitbucket.service
systemctl daemon-reload
systemctl enable gitbucket.service
gitbucket は JAVA 11 をサポートしているのだけど、JAVA 17 で動いてしまったので、こちらで動かしてます
DistroWatch Weekly, Issue 1063, 25 March 2024 から抜粋
Questions and Answers (by Jesse Smith)（元記事）
Slowing-things-down asks: ローリングディストリビューションがローリングレーベルを維持するためには、どれくらいの頻度でアップグレードしなければならないのでしょうか？私の知る限り、「ローリング」であることは、アップグレードの方法についてであって、頻度についてではないと思っています。ローリング方式は、最新バージョンを入手するための一般的な方法と認識しています。理論的には、ローリングディストロは滅多にアップグレードしないことで非常に安定し、安定性とアップデートの両方の長所を提供できるかもしれないと思ってます。ローリングリリースのアップグレードはどの程度遅いですか?
DistroWatch answers: ローリングリリースモデルを定義するのは、その頻度よりもむしろシステムをアップグレードする方法であるというのは正しいです。定期リリースのディストリビューションでは、一定期間パッケージは同じバージョンに保たれ、通常は次のリリースがくるまではセキュリティ修正（と、おそらく新しいハードウェアサポートの追加）が適用されるだけです。新しい機能を手に入れるには、ユーザーは通常、ディストリビューションの次のバージョンにアップグレードする必要があります。
ローリングリリースには、「任意のタイミングで」アップグレードされるパッケージがあります。ディストリビューションのリポジトリにある古いソフトウェアパッケージは、適時新しいバージョンのパッケージに置き換えられていきます。ディストリビューションは、リリースを一時停止したり、一定の時点でフリーズしたりせず、古いパッケージを新しいものに置き換えていきます。
多くのローリングリリース・ディストリビューションは、常に最新バージョンのパッケージを提供し、テクノロジーの最先端にとどまろうと努力していますが、そうである必要はありません。より保守的なローリングリリースもいくつかあり、よりゆっくりとアップグレードしたり、アップストリームソフトウェアの長期サポートバージョンにこだわったりして、より緩やかなローリングリリースを提供しています。
PCLinuxOSディストリビューションは、このスローリリースアプローチの好例です。このプロジェクトは、より古く、より試され、より忠実なソフトウェアに固執する傾向があります。また、新しいバージョンをよりゆっくりと慎重に採用する傾向があり、ユーザーにより安定した体験を提供しています。openSUSEプロジェクトは最近、Slowrollと呼ばれる新しいローリングブランチを実験的に導入しています。Slowrollブランチは、openSUSEの高速なTumbleweedブランチと比較して、より保守的なローリングリリースを提供することを目的としています： 「Slowrollは2023年からの新しい実験的なディストリビューションで、Tumbleweedをベースにしていますが、ローリングは遅くなっています。Slowrollは2023年からの新しい実験的ディストリビューションで、Tumbleweedをベースにしていますが、よりゆっくりとしたペースでリリースされます。
The Voidはまた、技術の最先端を維持するよりも、より安定したローリング・リリースを提供することに努めています：「The Voidは、最先端であることよりも、安定性を重視しています」
DistroWatch Weekly, Issue 1062, 18 March 2024 より抜粋
Questions and Answers (by Jesse Smith)（元記事）
Reading-is-for-everyoneからの質問です： media/uploadディレクトリに置かれたファイルをスキャンするcronスクリプトがあります。これらのファイルのパーミッションは644でなければなりません。これらのファイルのパーミッションをすべてのファイルに自動的に設定する方法はありますか？
DistroWatchの回答： ディレクトリに置かれたファイルが特定のパーミッションを持っていることを確認する方法はいくつかあります。この場合、644パーミッションの値は、ファイルの所有者がそれらを読み、編集できることを示しています。他のユーザー（ファイルの所有者グループのメンバーとシステム上の他のユーザー）は、これらのファイルを読むことができます。6は所有者の読み取りと書き込みのパーミッションを示し、2つの4はそれぞれ他のユーザーの読み取り専用アクセスを示します。
media/uploadディレクトリにファイルをアップロード、作成、または移動する各ユーザーのユーザーアカウントをある程度制御できると仮定すると、1つのアプローチとして、新規ファイルのデフォルトパーミッションを設定することができます。これにより、システム上のユーザーによって作成またはアップロードされたすべての新規ファイルに特定のパーミッションが設定されます。デフォルトのファイルパーミッションを設定するツールは、umaskと呼ばれます。
umask ユーティリティは、新しく作成されたファイルやディレクトリに対して、特定のユーザにどのパーミッションを与えないかを設定します。umaskコマンドは、8進数のパーミッション番号（chmodコマンドと同じ形式）を受け付け、新しいファイルに指定されたパーミッションを削除させます。例えば、ほとんどのシステムでは、umaskの値は022に設定されています。これは、所有者はパーミッションを削除されない（新しいファイルに対して何でもできる）ことを意味します。しかし、ファイルのグループのメンバーやシステム上の他のユーザーは、ファイルを編集するためのアクセス権（パーミッション2）が削除さ れます。
umask値は通常、ユーザーのシェルのスタートアップ設定ファイル（/etc/bash.bashrcや~/.bashrcなど）で設定さ れます。いくつかのディストリビューション、特にDebianファミリーでは、umask値は/etc/login.defsファイルで設定さ れます。
すべてのユーザーのumask値を022にしたいケースが多いので、多くのディストリビューションでは一般的なデフォルト値にされています。
とはいえ、ユーザーのumaskがすでに022に設定されていて、彼らがファイルのパーミッションを変更している、あるいは他の何かがパーミッションを変更している、あるいはあなたがユーザーのumaskを変更するアクセス権を持っていない場合、どうすればいいでしょうか？別の方法としては、cronジョブが実行される直前にファイルのパーミッションを変更することです。rootユーザーが以下のchmodコマンドを実行し、全てのユーザーに/media/uploadディレクトリ下のファイルへの読み取り権限を与えることでこれを達成することができます：
chmod -R a+r /media/upload/
上記の行を既存のスクリプトの先頭に置くか、スクリプトの起動前にルートユーザーのcrontabから実行させることで、/media/upload以下のすべてのファイルとサブディレクトリの読み取りアクセスが可能になります。
DistroWatch Weekly, Issue 1061, 11 March 2024 より抜粋
Questions and Answers (by Jesse Smith) （元記事）
Start-over asks： 毎日指定した時間に自動的にサービスを再起動する方法を探しています。ゲームサーバーをホスティングしていて、定期的に再起動させたいのです。ゲームはsystemdユニットで起動しています。
DistroWatchの回答： ほとんどのLinuxディストリビューションやBSDファミリーでは、スケジュールされたタスクを実行するツールはcronと呼ばれています。各ユーザは、実行したいタスクとスケジュールされたジョブの開始時刻をリストしたファイルを持っています。この時間とタスクをリストしたファイルをcrontabと呼んでいます。
コマンド "crontab -e "を実行することで、ユーザーアカウント用のcrontabを作成することができます（または既存のcrontabファイルを編集する）。このコマンドを実行すると、テキストエディタが開き、現在のcrontabが表示される。最初はおそらく空白です。
crontabファイルのフォーマットについては、crontabのmanページに概説されています。最も単純な形式では、crontabエントリーは5つの時間パラメーターと1つのコマンドを実行します。5つの時間フィールドは、ジョブを実行したい、分、時間、月、日、曜日を示します。次に、指定された時間に実行されるコマンドが続く。星印(*)は、時刻を常に一致させたい場合の時間フィールドを示します。
この例では、正午（午後12時）の1分後に実行する backup-everything というコマンドを実行します。これを毎月（*）3日に、曜日に関係なく実行します：
1 12 3 * * /usr/local/bin/backup-everything
次の例では、同じスクリプトを実行しますが、毎週月曜日の午前3:00に実行します：
0 3 * * 1 /usr/local/bin/backup-everything
どちらの例でも、スクリプトへのフルパス名を指定していることにお気づきかもしれません。"backup-everything "ではなく、"/usr/local/bin/backup-everything "と指定しています。これは、cronが実行可能なプログラムやスクリプトを見つけようとする際に、通常のユーザーアカウントと同じパスを使用しないことが多いためです。ほとんどの場合、cronジョブが正しく実行されないのは、パス名が不完全なためです。
元の質問に戻りますが、"game-server "というsystemdサービスがあるとします。このサービスを毎晩午前2時15分に再起動させるには、以下のcrontabエントリーを設定します：
15 2 * * /usr/bin/systemctl restart game-server
上記の例では、systemctlプログラムが/usr/binディレクトリにあると仮定しています。systemctlプログラムのフルパスを調べたい場合は、whichコマンドを使ってください
$ which systemctl /usr/bin/systemctl
crontabエントリーを作成したら、テキストファイルを保存し、テキストエディタを終了します。これでcrontabが保存され、指定した時間にゲームサーバーが自動的に再起動します。crontabファイルが正しく保存されているか再確認したい場合は、"crontab -l "を実行することで、あなたのユーザーのcrontabファイルの内容を見ることができます：
$ crontab -l 15 2 * * /usr/bin/systemctl restart game-server
複雑になる可能性があるのは、パーミッションの問題です。通常のユーザーアカウントにゲームサービスを再起動する権限がない場合（またはゲームサービスを起動するのにsudoが必要な場合）、自分のユーザーのcrontabからゲームサーバーを再起動しようとすると失敗します。通常、sudoを使用してサービスを開始する場合、またはゲームサービスを起動するためにrootユーザーを必要とする場合は、自分のユーザーのcrontabではなく、rootユーザーのcrontabを編集する必要があります。
ほとんどのディストリビューションでは、"sudo crontab -e "コマンドを実行することでこれを行うことができます。これにより、ルートユーザーのcrontabが編集され、自分のアカウントの権限制限が回避されるはずです。
