Debian GNU/Linux スレッド Ver.93

extend:checked:vvvvv:1000:512
extend:checked:vvvvv:1000:512
次スレを立てる方は↑を二行重ねて書いてください

公式
https://www.debian.org/index.ja.html

過去ログは各自検索して見つけること
大体参考にならないので過度な期待は禁物

前スレ
Debian GNU/Linux スレッド Ver.92
https://mao.5ch.net/test/read.cgi/linux/1565609547/

最近知った
https://parrotlinux.org/

systemdのほうがサービス書くの楽。

systemdにはだいぶ慣れたけど ip ss には未だに慣れない・・・

今のところはsystemdを便利に使ってるけどなあ
将来どうなるのか

今更、何を投票しているんだい？

>>237
サンドボックスってどういう意味なのかな?

すまん、言葉足らずだった　サンドボックスにしてもバックグラウンドでウイルスや不正な動きをされた場合、
検知出来ないのでは?

>>243
sandboxに脆弱性がなければいいんでない？

systemdのほうがサービス書くの楽。
これは正しい。

だけどそれは設定ファイルの形式の問題

特定のパッケージが最新版か調べる（より簡単な）方法はないでしょうか？

apt では駄目かね
あるいは https://packages.debian.org/buster/mlterm みたいなの

apt updateで駄目なん？

「何」より簡単なのを求めてるのかわからんけど

apt-cache policy hogehoge

とかじゃダメなん?

シェルスクリプトで条件分岐したいという話です。

理想

if apt-get is-upgradable hogehoge; then
　echo hogehogeはアップグレードできるよ！ここでアップグレードしていくかい？
　# y/nを入力させてyなら実行
fi

apt list --upgradable | grep hogehone

これさえなければなぁｗ

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

一覧表示...

パイプ挟むならapt-getじゃないの

コマンドラインでは apt
シェルスクリプトでは apt-get

という使い分けだと何処かに書いてあった気がするけどソース失念

ブラウザーでアプリケーションのソースをDLしたいのだけれど
.debみたいにまとまったやつない？
ファイルごとのバラバラのディレクトリなら見つかったけど
それをまとめてDLするのができない

firefox で URL をコピーして wget してるな、そういうの
それ以外の方法は分からん

>>252
有難う。この使い方知らなかったので、とても勉強になった。

apt-get のシミュレーションモードで grep 2 回使いですが、
こんな感じでしょうか。

#!/bin/sh
CMD=hoge
if apt-get -s -u upgrade | grep Inst | grep $CMD ; then
echo $CMD アップグレード出来るぴょん
fi

なんでてめーがこたえてんだ

>>256
dget -u xxx.dscを使いたくない/使えない理由は？

>>260
その dget というものが無い

>>261
sudo apt install devscripts

漏れは、Windows10, WSL, Ubuntu16.04 で、Ruby スクリプトで、
apt-get で、全パッケージの更新をしてる

#!/usr/bin/ruby
# frozen_string_literal: true

# 全パッケージの更新

# sudo のパスワードを自動入力する
# echo <your_password> | sudo -S <your_command>
puts `echo ここにパスワード | sudo -S apt-get update`

puts `sudo apt-get upgrade -yV`

RubyよりPythonのほうがいいんじゃないか
デフォルトで存在するし

何かビッグなことをやるための、はじめの一歩で導入したんだろ

Rubyって便利そうだな、知らんけど

debian10で、追加したNVMeSSDにデータを書き込みたいんだけど
フォーマットしてマウントしたはいいけどデータ送ろうとすると
ファイル操作は完了しましたがエラーがあります。
って出て、エラーの内容はError creating directory〜〜〜〜
なんですけどどうすれば良いですか？

>>263はム板の無関係な言語のスレの至るところでRubyの的外れな回答を繰り返す名物キチガイだから相手にしちゃダメ

今はプライベートで Ruby 使うのは変人だけと言っても過言ではない

>>267
>Error creating directory〜
このエラーメッセージで検索すれば？

マウント用のfstab という設定ファイルが、今もあるのか？
readonly でマウントしていて、書き込みできないとか？

>>269
Rubyは高脳しか使わないが正しい。
でも、高脳には変人が多いからな

>>264
LinuxユーザーにはPythonを超活用している奴がものすごく多いから
デフォルトで入れているディストロが多いよな。
おかげで、Pythonのことはプログラム板よりLinux板で尋ねたほうがずっと良い
という感じだからな。

パイソンを学ぶ
https://www.youtube.com/watch?v=ou6AGNE4RJE

Debianは安定しすぎてupdate＋upgradeしかやることがないから面白くないって云う人も居るかも

>>273
バージョンを上げるのが面倒だけど、それは他も同じだし

aptの説明（原文）が間違ってるんだけどどこに言えばいい？

aptitude show hoge の意

間違った説明を書いているもののBTSへ投下すればいいんじゃないの？

BusterでDebianデビューした俺がノーパソ@uefiブートにStretchをインストールしてみた

https://i.imgur.com/VzHOAjF.jpg

なるほどこりゃひどい
初心者が近寄らないわけだ
grubの解像度設定、それもインストールメディアのgrubの設定なんか初心者が分かるわけないもんな

PCスペックも開示しないでか？　手順を踏まないとただの愚痴でしかない

>>279
失礼した
全くその通り
スペックはこんな感じだけど情報としては十分かな？
https://i.imgur.com/xRDHlnl.png

何で今時 Debian 9 stretch をインストールして文句書くんだ。
意図的な嫌がらせか。

考え過ぎだな
Busterになって色々改善されたと聞いていたので、ではそれ以前はどうだったのかと興味が湧いただけだし
インストールさえ出来ちゃえば極めて快適だね

そういう場合はGUIを使わない設定でインストールすればいいのではないか

Buster でどれだけ改善したか
過去のすさまじい悪評は何だったのか


確認のために stretch をブートしてみるのくらい
フツーフツー

仮想マシンにインストールすればよくね？

>>283
残念ながらテキストモードでも同じ症状でしたな
Buster初インストールの時はあっけなく終わっただけに面喰らいましたわ
284さんがおっしゃるすさまじい悪評が何だったのか、どれだけ改善したのか、
興味深いのでしばらく常用して体験してみたいと思います。
日常用途に必要な環境はBusterから同期済なので。

USBメモリーからインストールしたのなら、それが問題かも　unetbootin使ってましたとか
CDからならどうでしょうね

>>287
USBは普通にddrescueで作成したものです
このスレでも悪名高いUNetbootinはさすがに使いませんね。
面白そうなので円盤からのブートで検証してみます
只今久しぶりにDVD作成中

>>287
追記
この現象の原因は特定済み(デフォルトのgfxmode=800x600とブートメニューに
もれなく記載されているvga=788が当方環境に合わない)で、
rufusで作成したUSBでgrub.cfgを修正してインストールしました。
只今インストールしたStretch上で作業しています。

>>287
https://i.imgur.com/QMZD6xc.jpg
やっぱりダメでした(泣)
尚、↓こちらはgrub.cfgを手直し(set gfxmode=1366x768に修正　vga=788をブートメニューから消去)してブートした様子
https://i.imgur.com/Pkowy8L.jpg
282にも書きましたがインストールさえ済めば至って快適そのものですな

最初の画像見えないからわからんけど、今まさに悪評らしきものを体験できてるんじゃないか

君なら良いDebian Desktoperになれそうだ

>>291
https://i.imgur.com/Fn1d0cz.png
最初の画像をeogで閲覧しているStretchの様子です
今のところデスクトップとしての問題は感じられません

>>292
有難うございます
ディストリビューションの名に恥じないDesktoperを目指したいと思います

>>236
systemd排除する方向の投票はどれなんだ…

>>295
しかしsystemdは速いからの・・・
受け入れねば村は滅びるしかないのじゃ

速いとかいう触れ込みの実
速度変わらなかったやつね
systemd滅ぶべし

でも起動時の自動起動処理を書くのが簡単だからな…＞systemd
そこだけ取り出した init があればなぁ

まあ速度より開発リソースの問題だろう
企業主導で開発が進む現代のLinuxにおいて、Debianの烏合の衆が独自路線でついていくのはもはや無理

ユーザーにメリットもないのに沸く謎のsystemd推し
滅べ

systemdの開発ろくにしてねえ一体なにしてるんだ？とニュースになったばかりなのに
開発リソースも糞もないというね

企業の力をもってしても開発が回らないなら乞食衆が独自路線を選ぶなど不可能だと気付け

不自然な成果物に不自然な擁護
マジ滅べ

スポンサーの意向に従ったけど肝心のスポンサーからの実入りが減ったとかそんなとこかね？

最近の情勢知らんけど
sysvinit 系みたいなの残ってんの？

派生鳥で systemd 排除したモノがあるらしいけど
LXQt みたいな感じで合流？するの？？

本気でユーザーにメリットないと思っているんか？
底が浅いのぉ

Debianでいえば、現状はsysvinitもあるしそれ以外の実装openrcとか
runitとかもある

systemd以外もサポートしなければならない、多様性を認める程度、
はてはsystemdのみサポート、というレベル感の違う選択肢が投票の
オプションとして用意されてる

どれがどういうものかをまとめたIanのblog記事が参考になる
https://diziet.dreamwidth.org/3999.html

systemdが使用してるメモリ量ってどこを見ればいいの？
少ないんだとは思うけどユニットファイル追加したらどれくらい増えるんだろうか？

Systemdの使用法書かれた記事はあっても
initと数値を比較して優位性を示した記事は見たことがない
メリットとされていたのは口先だけの誤魔化しで実際はデメリットばかり
ブラックボックス化して悪巧みしたいのだろうとだけ感じる

systemdのメリットは数値じゃなくて便利さでしょ？
initが起動時したときだけの処理をしてるのに対して
systemdはシステムの動的な変化をトリガーに処理を行う

システムが起動した時だけじゃなくて
ディスクがマウントされたとか特定の時間になったとか
ネットワーク構成が変わったとか
数値の前にinitは機能が足りてないんだよ。

あとinit.dのスクリプトが面倒くさい。自分でpidファイルを作ってとか
start/stop時の処理を書いてとかやらないといけない。
自分で新しいアプリを作ったときに必要になるコードの量がぜんぜん違う
あ、コードの量なら数値でわかるかｗ

毎回ゼロからでなし
比較として適切かどうか

「Java はコードが長いからダメ」っていうのとどう違うか説得力もたせないと

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ ] Choice 1: F: Focus on systemd
[ ] Choice 2: B: Systemd but we support exploring alternatives
[ ] Choice 3: A: Support for multiple init systems is Important
[ ] Choice 4: D: Support non-systemd systems, without blocking progress
[ ] Choice 5: H: Support portability, without blocking progress
[ ] Choice 6: E: Support for multiple init systems is Required
[ ] Choice 7: G: Support portability and multiple implementations
[ ] Choice 8: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


Voting period starts 2019-12-07 00:00:00 UTC
Votes must be received by 2019-12-27 23:59:59 UTC

systemctl statusは便利

あと/etc/systemd以下にファイルを配置することで
簡単にデフォルト設定を変更できるのもいいな
以前はインストールすると勝手に起動するサービスを
停止させるのは面倒だった

>>311
Javaのコードの長さは型情報の追加という意味があるから全然話が違うよ。

init.dの場合、initが面倒を見てくれれば書かなくて済むものを
自分で書かなければいけない。しかもそのやり方はディストリごとに
パスが違ったりと微妙に異なる可能性がある。

なにより量が違いすぎる。/etc/init.d/cronは少ないほうだと思うが92行もある
それに対して/lib/systemd/system/cron.serviceは12行

>>312
今のままのinitの使い方はやめるべきだと思うな
init自体はそのままでも良いと思うんだけど、
init.dのスクリプト群にフレームワーク的な構造をを取り入れて
処理を共通化するべきだろう。そしておそらくそれはできる。
start/stop/status的なものはデフォルトで共通処理
そしてオーバーライド可能とかね
そうしないとメンテナンスが大変すぎる。

Debianをsystemdに売り渡した連中がデカイ面してるので
出ていった半数のメンテナは戻ってこない
つまりDebianが暗黒面に落ちたから*BSDへ移る用意をしておけということだ

要するに、sysvinit かなにかをデフォルトにして
「選びたければ systemd にしな」というかんじにしたい人が結構多いのかな

>>317
そんな事言っちゃっていいの？
間違いなくドライバ云々で苦労する人続出だよ

systemdってexponential backoffないのか？つらいな
デフォルトは10秒間で5回まで再起動が行うっていうけど
起動に3秒ぐらいかかってるから、10秒で5回の閾値超えないんだよな
つまり永遠に再起動を繰り返す。
ちゃんとそこまで確認して設定すりゃいいんだろうが
簡単にミスしてログでディスク枯渇してしまう

>>318
blogでどう投票したかを表明している人の内容を見てる感じ
systemd推進派とinit多様性維持派で半々ぐらいの印象
まあN=1桁だけど

systemdオンリーにする方針は
何年かしたら再考しようと誰か言い出すし
蒸し返すの禁止にも出来ないし

エラーの原因が一時的な要因（ネットワークエラー）によるものと
恒久的なもの（設定ファイル記述ミス）とで分ける仕組み無いかな
一時的なものならsystemdでリトライしてもらいたいが、
設定ミスとかリトライしたってしょうがないだろうと

つーかリトライ上限すら無いんだな

変数展開にExecStart=/bin/sh -cが広く使われてるワークアラウンドってのがダサいな
これのせいで絶対パス限定にした意味がなくなってるし

まぁ、簡単にサービスを定義できるようになったから、逆にテキトウな設定で済ませてしまう（いわゆるコピペ）開発者やメンテナが増えてしまうっていうパターンだな。
RestartPreventExitStatus とか StartLimitBurst とかいろいろ仕組みはあるから…。

どこもかしこもsystemdってことは迎合してでも採用する利点があったってことじゃないの？
古来からの文法が刷新されて一から覚え直すハメになったのは分かるけど、
だからって開発者にまで批判ってどんだけ嫌われてるのコレ
Linux版のsvchost.exeってことで色々察したけどさ
swapも最近になって専用領域からファイルに変わったけどそこまでwindowsの後追いしなくてもなぁ

不便にはなった
無理やりねじ込んできた様にしか感じない

別に不便とは思わないんだが、ユニットファイルの形式がなー

hogehoge.service.sh みたいな名前で、こんな形式の
シェルスクリプトだったら良かったのにな


description="説明"
before=
after=

exec_start() {
　起動コマンドを書く
}

exec_reload() {
　再起動コマンドを書く
}

宣言的に書くのがミソなのに
そんな書き方許したら駄目だな

>>322
まあそういうのはどういう方向に行ったとしても禁止はできない
それでも本格的にどうするのかを決めるまでにいくのはそんなに簡単でもない
今回でもMLで議論 -> Technical commiitee内で議論 -> GR という
過程を経ているし蒸し返す際にも同じ過程を踏む必要がある

で、蒸し返しの場合だったら一回GRで決まったんだからTCが否決する
可能性が高いんじゃないかな

なんでfetchmailは、ベータ版をstableに採用したんだろう
旧版はセキュリティ的に問題あったのかな

>>330
実行順がないところは宣言的でいいが
起動順が重要なところは宣言的じゃないほうが良いよ

例えばEnvironmentとExecStartPreはどちらが先に実行されるか？
こういう処理は本質的に宣言的ではない

すべてを宣言的にやろうとしすぎて逆に複雑になってる気がする

>>332
fetchmail 使えない？ うちではこんなエラーが出ている。

$ fetchmail
fetchmail: OpenSSL からの報告: error:1414D172:SSL
routines:tls12_check_peer_sigalg:wrong signature type
fetchmail: SSL による接続に失敗しました。

strech で不自由していないから、そのうち直るだろうとほっぽってあるんだが。

debian10.2のnetインストのハッシュを確認したいのですが、
相変わらずサイト構成が解りにくく、たどり着くことが出来ません。
チェックサムはどこに記載されていますか？

>>335
まずネットインストの場所を教えて下さい