2021年 03月 01日
zabbix 5.2 openSUSE Leap 15.2 SNMP でデバイス監視
Zabbix4 はこちらZabbix4.2 snmp監視 デバイスのグラフを表示させるまで


1 CONFIGURING A HOST










あわせて読みたいZabbix 5.2 on openSUSE Leap 15.2 インストールzabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定
2021年 02月 25日
Zabbix 5.2 on openSUSE Leap 15.2 Install
openSUSE Leap 15.2 Install First Look.(インストール)
openSUSE Leap 15.2 Web LAMP install with YaST(動画、音出ます)



rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpmzypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'

# SUSEConnect -p sle-module-web-scripting/15/x86_64
zabbix-server-mysqlzabbix-web-mysqlzabbix-apache-confzabbix-agentzabbix-web-japanese (<- 日本語化する場合必要)

mysql の root パスワード : mysqlpwdZabbix Database 名: zabbixdbZabbix Database ユーザ/パスワード: zabbix/zdbpwd
mysql -uroot -pmysqlpwdmysql> create database zabbixdb character set utf8 collate utf8_bin;mysql> create user zabbix@localhost identified by 'zdbpwd';mysql> grant all privileges on zabbixdb.* to zabbix@localhost;mysql> show databases;mysql> quit;
zcat /usr/share/doc/packages/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbixdbEnter password: zdbpwd
gedit /etc/zabbix/zabbix_server.conf &DBUser=zabbixDBName=zabbixdbDBPassword=zdbpwd
systemctrl restart zabbix_server zabbix_agent apache2systemctrl enable zabbix_server zabbix_agent

firefox http://localhost/zabbix &


Database name: zabbixdbuser: zabbixpassword: zbxpwd





Login:Admin/zabbix (デフォルト初期値です case sensitive 大文字小文字注意)




・データベース名、DBユーザ名、パスワードは事前に決めておく事です。ダウンロードページの指示通りでも構いませんが、デフォルト password じゃいかにもですからね。大抵、何らかのエラーが起こるとすれば、この三つの設定がおかしい。・Web LAMP のインストール手順が、サジェスチョンに含まれていないので、事前にインストールして mariadb を起動しておく事。・WebUI へのログインは Admin/zabbix です。ケースセンシティブ、大文字小文字注意です。クラウド運用する時は早めに変更しておく事。・ UI のURLは、http://ip-address/zabbix です。/index.html を書き換えて、リダイレクトすると良いでしょう。
zabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定zabbix4.2 を zabbix5.0 アップデート
2020年 12月 02日
openSUSE 15: zabbix5.0 から 5.2 へのアップデート


BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保
/var/lib/mysql/zabbix
7 Snapperを使用したシステムの回復とスナップショット管理 REPORT DOCUMENTATION BUG#
- リポジトリを変更して- YaST でアップデート- YaST で Zabbix を再起動
zabbix5.2 ダウンロード

zabbix:~ # rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpmRetrieving https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpmPreparing... ################################# [100%]Updating / installing...1:zabbix-release-5.2-1.sles15 ################################# [ 50%]Cleaning up / removing...2:zabbix-release-5.0-1.el15 ################################# [100%]zabbix:~ # zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'Retrieving repository 'Zabbix Official Repository' metadata ................................[done]Building repository 'Zabbix Official Repository' cache .....................................[done]Specified repositories have been refreshed.zabbix:~ #



opensuse151:~ # systemctl restart zabbix-server.serviceopensuse151:~ # systemctl restart zabbix-agent.service

2020年 11月 18日
PDCAサイクルから考えるセキュリティポリシーの見直し

PDCAサイクル
-1. Plan : 計画-2. Do : 実施-3. Check : 見直し-4. Action : 執行
コンピュータ名(ホスト)の命名規則? 15文字の63バイト制限、ホスト名の命名権利はだれの責任?
ユーザアカウント名は8文字以内にすべきか?ユーザの命名規則の理由と対策
「取引先の要求でこんな感じで文書ファイルを扱わなければならない」
「パスワードは難しく、かつ簡単にこんな風に個人的に管理している」
霞ヶ関でパスワード付きzipファイルを廃止へ 平井デジタル相
2020年 07月 26日
BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保

どんなショボいシステムでも、安易に変更は加えない方がいいわけです。openSUSE Leap 15.1 のシステムを# zypper dupしたところ、見事に罠にハマりました。BtrFS の罠です。スナップショットを取っているので、空き容量がなかったんです。空き容量がないところでパッケージのアップデートなんかすると、openSUSE Leap 15x はルートパーティションが Copy On Write の BtrFS ですからファイルは上書きではなく、差分をドンドンと CoW してしまう。遂にディスクの空きを使い果たして、中途半端な zypper dup の結果、「システムが立ち上がらない」という最悪の結果に陥りました。BtrFS のスナップショットの残骸ってロック掛かっていて、レスキューディスクで起動しても消せないのですね。という事で、BtrFS のファイルシステムに変更を加える場合は「空き容量を確認して空きを確保してから行え」という「鉄の法則」を学びました。
How much free space do I have? or My filesystem is full, and I've put almost nothing into it!
1 Linuxファイルシステムの概要
これらのドキュメントによるとopensuse151:~ # btrfs fi showLabel: none uuid: 8466aee4-2738-4b0a-924a-79edad4b4676Total devices 1 FS bytes used 8.13GiBdevid 1 size 14.00GiB used 10.57GiB path /dev/vda2opensuse151:~ #"ファイルシステムの合計サイズとその使用量を表示します。最後の行のこれら2つの値が一致する場合、ファイルシステム上の領域はすべて割り当て済みです。"上のケースでは14Gbのデバイスサイズのうち、 10.57Gb 使用中です。
opensuse151:~ # btrfs fi df /Data, single: total=8.01GiB, used=7.50GiBSystem, DUP: total=32.00MiB, used=16.00KiBMetadata, DUP: total=1.25GiB, used=641.95MiBGlobalReserve, single: total=30.22MiB, used=0.00Bopensuse151:~ #
"ファイルシステムの割り当て済みの領域(total)および使用済みの領域の値を表示します。メタデータのtotalおよびusedの値がほぼ等しい場合、メタデータ用の領域はすべて割り当て済みです。”
メタデータ 1.25 Gb 中、641Mb 使用中です。opensuse151:~ # btrfs fi usage /Overall:Device size: 14.00GiBDevice allocated: 10.57GiBDevice unallocated: 3.43GiBDevice missing: 0.00BUsed: 8.76GiBFree (estimated): 3.93GiB (min: 2.22GiB)Data ratio: 1.00Metadata ratio: 2.00Global reserve: 30.22MiB (used: 0.00B)Data,single: Size:8.01GiB, Used:7.50GiB/dev/vda2 8.01GiBMetadata,DUP: Size:1.25GiB, Used:641.95MiB/dev/vda2 2.50GiBSystem,DUP: Size:32.00MiB, Used:16.00KiB/dev/vda2 64.00MiBUnallocated:/dev/vda2 3.43GiBopensuse151:~ #”前の2つのコマンドを組み合わせたのと同様のデータを表示します”
つまり btrfs fi usage <mount_point> が一番使われやすいコマンドだという事です。
duコマンドは当てになりません。ncdu でルートからスキャンしたらこれ。このシステムは物理的に25Gbしかない仮想VMです。

スナップショットサイズが「150Gb 使用中」と、あり得ない数字を示しています。
こちらの文書の中に
How much free space do I have? or My filesystem is full, and I've put almost nothing into it!
"So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet."
"したがって、一般に、btrfsファイルシステムの空き容量を正確に見積もることは不可能です。はい、これは最悪です。ユーザーがどれだけのスペースを残したかを簡単に理解できるようにする方法について本当に良いアイデアがある場合は、私たちに知らせてください。また、btrfs開発の最高の心がこの問題について考えていることに注意してください。少なくとも数年間は、簡単な解決策はまだ見つかりませんでした。"
例えば、openSUSE Leap 15.x では / (ルート)の BtrFS パーティションは、最低でも 15Gb のサイズ以上確保しておかないと、インストールの際、警告が出ます。実際のインストールで使用されるディスク容量は openSUSE Leap 15.2/SLE15 で 7.5 Gb 程度です。SLE12 では6Gb 程度でした。空き容量の把握は難しいので、長期運用でバージョンアップに伴い必要とされる空き容量は、将来に渡って不明です。将来バージョンアップしたり、パッチを頻繁に充てるクリティカルなシステムなら 25Gb ~ 30Gb 程度のルートパーティションサイズが欲しいところです。「ディスク容量を食う」点は、誰も指摘していませんが BtrFS の隠されたデメリットです。もし、コンパクトで JeOS な仮想サーバーを作りたいのであれば ext3、4 などの古来のファイルシステムを検討すれば 10Gb 程度でも使えるわけです。
デフォルトではシステムは毎週 scrub によるメタデータの修復、デフラグ、破損ファイルの修復を実行します。scrub はファイルシステムの破損などがないかメタデータをチェックし、自動修復する機能です。sysconfig に設定されます。BtrFS の信頼性を確保するための重要な機能です。

手動で scrub するには# brtfs scrub start <mount point>を実行し、 btrfs scrub status -d -R <mount point> で結果を確認できます。
スナップショットの作成と削除は自動化されています。こちらの文書によると SUSE Linux(SLE15) においては
7.1.3.4 スナップショットのアーカイブの制御
"デフォルトでは、最大10個の重要なインストールスナップショットと管理スナップショット、および最大10個の標準のインストールスナップショットと管理スナップショットが保持されます。これらのスナップショットがルートファイルシステムのサイズの50%超を占有する場合、追加のスナップショットは削除されます。最低でも、4つの重要なスナップショットと2つの標準スナップショットは常に保持されます。"
とあり、この定義は snapper -c MySnapConfig create-config <partition> によって作成された /etc/snapper/configs/ にされた MySnapConfig ファイルによって定義されます。
7.4.1 既存の設定の管理
7.6.2 タイムラインスナップショットのクリーンアップ
それぞれ、スナップショットの作成と削除はタイムラインによって snapper -c MySnapConfig ファイルに作成されます。
opensuse151:/etc/snapper/configs # cat mysnapconfig | grep TIMELINETIMELINE_CREATE="yes"TIMELINE_CLEANUP="yes"TIMELINE_MIN_AGE="1800"TIMELINE_LIMIT_HOURLY="10"TIMELINE_LIMIT_DAILY="10"TIMELINE_LIMIT_WEEKLY="0"TIMELINE_LIMIT_MONTHLY="10"TIMELINE_LIMIT_YEARLY="10"opensuse151:/etc/snapper/configs #
通常運用では問題にならないので、デフォルトの scrub のタイミングも、スナップショットを有効化した場合の、スナップショットのメンテナンス間隔は、そのままで構わないでしょう。
手動でのスナップショットの状態、最新のスナップショットの状態確認は YaST2 Snapper で確認し、内容のチェックとロールバック、削除などの操作を行います。

4.1.1 スナップショットとディスク容量
”ヒント: 容量を空ける/ディスクの使用率スナップショットを含むBtrfsパーティションの容量を空けるには、ファイルではなく、不要なスナップショットを削除する必要があります。古いスナップショットは、最近のスナップショットよりも多くの領域を使用します。”
とある様に、アップデートに必要な空き領域を確保するには、古いスナップショット、意図的に取得した古いスナップショットを削除して、空き領域を確保し、 btrfs fi usage <Partition> か btrfs fi df <Partition> コマンドで空き容量を確認し、その後、明示的にアップデートからのスナップショットロールバック、復元ポイントを作ってから、アップデートを実施すべきでしょう。
忘れてはならないのは、zypper up や zypper patch など、あるいはメジャーアップデートする時、同じファイルであっても物理的なファイルそのものが上書きされずに、古いファイルはスナップショットに「移動」し、空き領域に新しいファイルが作られることです。

2020年 05月 31日
zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック
How to setup zabbix4.2 on openSUSE Leap 15.1 セットアップhttps://islandcnt.exblog.jp/239366228/
zabbix4.2 を zabbix5.0 アップデート openSUSE Leap 15.1
https://islandcnt.exblog.jp/240337666/
- Google などの海外の大手- Google DNS の様な巨大インフラへの Ping 監視- 契約先の経路の短い Web サイトの HTTP 監視- 契約先の経路の短い NTP サーバーへの Ping 監視











Softbank Air: Wifi ネットワークの暗い闇、シェアード IP

2020年 04月 08日
誰が買う? Windows10 タブレットは失敗作
いうまでもなく Windows はPC分野の80数%のシェアがあり。10数%が Apple 残りが Linux という事は、いろいろなリサーチにある訳ですよ。じゃぁ、インターネットのサービスを受ける、あらゆるデバイスの何パーセントが Windows なのか。スマートフォン、タブレットを含めれば、恐らく50%もないんじゃないでしょうか。多分スマートフォンが過半数なので、実際の「インターネットにおける Windows のシェア」はPCだけで3割もあればいいほうでしょうね。
Windows10 で最低限欲しいと思うスペックを考えると Core i3m とか i3yと言った Core 3 系のモバイル向けCPU が欲しくなるところです。ディスコンになった Atom 系SoCでは人を馬鹿にしている。正統派 Celeron でやっと使える感じがします。Windows Update を問題なくこなせて、安定して使うには、最低64Gbのストレージが欲しい。しかし、「Window が動くタブレット」として考えるなら、256Gbのストレージが欲しくなってしまうでしょう。そう考えると、自動的に12~3万円程度は最低限予算が必要なんですよね。しかし意外と Core i3 系のCPUは人気がない。というかメーカーもこのクラスより、より高価な Core i5/7 系を売りたがる。こうなると安くても15万円コースですね。キーボードもマウスもない Windows に15万円も普通払いません。しかし、「Windows デバイスを快適に使う」なら、オプションのキーボードとマウス、あるいはデジタイザペンは必須です。それなら普通のクラムシェルか 2 in 1 ラップトップを私なら選びます。2Gbのメインメモリ、32Gbのストレージ、Atom系 SoC では、「一応 Windows が動くタブレット」でしかなく、実際に使い物になるとは思えません。それでもWindowsがとりあえず動く環境にするには5万円前後するわけで、この値段で Android や iPad などの他社製タブレットならすコスコつかえるわけですよ。
大体、 Windows はフットプリントが重すぎて、タブレットには向かないぞ、という事だ。GIGAスクール構想の実現について1人1台のPCで教育のICT化を推進――日本マイクロソフトが「GIGAスクールパッケージ」を提供開始Google、管理などの無駄な時間を減らし4万5千円以下で提供可能な「Google GIGA School Package」を開始この勝負、どうみても Google に分があるんだが、どんなものでしょう。GIGA スクールパッケージに Windows は勝ち目がない。3万円の Android や Chrome タブレットを子供の Youtube 端末として使わせている親が、わざわざその倍の値段もして、華奢で壊れやすく安っぽい筐体の7万円の Windows タブレットを買うわけにはいかない。私が、中高で「情報C(情報社会)」を教える立場だったら、間違えなく Windows10 タブレットは「アウトオブ眼中」です。Chrome Book で安く済ませて、余った予算を別に使う事を考えるでしょう。
![]() [サーフェス プロ 6 ノートパソコン] Office Home and Business 2019 Windows 10 Home マイクロソフト Surface Pro 6 | ![]() (最新モデル) iPad mini Wi-Fi 64GB | ![]() タブレット 8.0インチ Wi-Fiモデル HUAWEI MediaPad M5 lite 8 |
スリープ解除して、通信が開始されるといきなり始まる Windows アップデート、いざ使おうとすると半日は使えないモバイルデバイス。それが Windows10 タブレットの宿命。毎月のアップデートだけで、格安SIM二月分のパケット料金と貴重な時間を使いたくない。そんなものに普通15マン近い大金払いませんって。よっぽど Apple の iPad がひどくてもこんなにひどくはない。それにもっとシンプルで堅牢なハードウェアだし、軽くて高性能、高機能なのです。4万円も出せば普通に使えるし、128Gb程度のストレージがあれば、スチルカメラやビデオカメラ並みに使える。それに iOS や Android, Chrome タブレットは機能を絞っただけシンプルで長時間のモバイル運用ができる。
街を歩いていて、ちょっと調べ事をしたいと思えば、スマートフォンより小型のタブレットは実にいい選択なのです。だけどそれが Windows タブレットとなれば、たとえタブレットと言えども、そこに "Windows らしさ" を求めるユーザ需要があるのですね。たとえタブレットであろうとも Microsoft Office が使えないと嫌だという、ユーザの奇妙なわがままを満たす必要があります。 Office アプリが必要であれば、当然マウスとキーボードもいるよね。「いざという時 MS Office が使える」という事は、その「いざと言う時」のために普段使わないキーボードもカバンに入れておく必要があるわけです。そして充電用のアダプタとケーブル。もう、 Windows10 なんて、一般家庭では「年賀状の印刷に年に一度使う」ためにある、というのが実態じゃないでしょうか。
最近の銀行取引では、大体 iOS か Android のタブレットで最適化されたアプリケーションが頒布されていまして、もし Windows タブレットで、銀行振り込みしようと思ったら、別に iOS か Android が必要と言う矛盾、無駄。そもそも、銀行振り込み用のアプリがない、どころかワンタイムパスワードアプリもない。携帯電話必須という不自然さ。ちなみに、 Windows ストアから片っ端に、大手都市銀行の名前を入れて調べると良い。一体、どこの預金者が、Windows OS を信頼しているんだろうってくらいに、ストアアプリは、銀行から嫌われています。頼むから Windows 端末から、預貯金の操作してくれるな、という位の総スカン状態なのですね。Windows PCのブラウザ経由で決算してくれるなって位の嫌われようなのです。専用の exe アプリケーションすら配布されない。 Windows は金融機関から唾棄され嫌われているのです。
ご存知の通り、 Windows Mobile はディスコンになり、既にサポートも終わっているわけで、 Microsoft としては、「マイクロソフト部屋に最後に残った幕内力士:Windows10」 をモバイルデバイスの切り札に残しているわけです。徳俵にかろうじて親指が残った崖っぷち張り出し大関、小錦みたいな状態。とてもじゃないけど、こんな危なっかしいOSを、フットプリントの小さな x86 環境にインストールして使う事自体、燃えないゴミにお金を投資するようなもの。Windows10 タブレットは、もはや大相撲の中日に全廃している張り出し大関のようなものです。とてもじゃないけど、私は「Windows10 タブレット」には、「引退という引導」を渡すべきだとおもいます。
これほど、顧客が混乱しているのは Intel のブランド戦略が破綻しているからなのですね。もっとブランドを整理すべきです。「Celeron に名前を変えた Atom」 があったり、ほとんど使われない Pentium があったり、低スペック、低電圧版の Core i3/i3m/i3y なんてモデルがあるのはいかがかと思います。その未整理な Intel のブランディング戦略にただ乗りしている、タブレットベンダーも責任を取るべきでしょう。「2コア4スレッド搭載タブレット」とか言っても、中途半端な Atom 系 Celeron だったりするわけで、ほとんど消費者騙しです。2コア4スレッド搭載「パーソナルコンピュータ」であれば、最低でも Core i3 程度を想像するのですが、よーく仕様を見ると Celeron でしかも Atom 系コアだったりします。※ Nxxxxx Celeron というNで始まる Celeron は、バチモノ系だそうです。つまり、もう生産中止になって在庫がごっちょりある Atom 系 CPU の悪く言えば生産余剰した、リマーク品なのですね。 これを消費者に 「Atom とは別物」と言う、リ・ブランドして売りさばくのが Intel の今のやり方なのです。Celerorn 選ぶくらいなら AMD の Ryzen 系、モバイル SoC 選んだ方がよっぽどウソがない気がします。
それでも Windows10 タブレットのニーズは根強くあるでしょう。それは「組み込み用途」です。こないだガス屋の端末見たら、Windows タブレットでした。 Windows 7 だったけど。しかし、企業でこういった外勤者に何百台と使わせるとなると、コスト、持ち運びの容易さ、堅牢性、電池の持ち、アプリケーション開発の容易さなどを考慮すると、別に、保険のオバちゃんが Windows タブレットを使わなければならない必然性はありません。ブラウザ経由のアプリケーションであれば、別に何でもいいんです。
ということで、Windows10 タブレットの将来性のなさ、致命的な欠点、わざわざ選ぶ理由がない事などをズラズラとまとめてみました。それでも Windows10 タブレット買いますか? それとも Android や Chrome, あるいはPC化する iOS 搭載 iPad ? もうタブレット戦争では、ほとんど Windows 10タブは「アウトオブ眼中」、タブレットOSシェアのパイチャートでは「その他」に分類されるようになるでしょう。
202x 年 Windows 最期の日
2020年 02月 27日
SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット
久しぶりに SUSE 11 の仮想マシンを起動したら、見事にコケました、仕方がないので、 fsck して起動しましたが、あまりいいものじゃありません。SUSE Linux Enterprise 12 から採用され、以降 SUSE Linux 15(SLE/openSUSE15) で openSUSE Leap で使われている BtrFS は、やれ「修復のため起動時の fsck の必要がない」とか、fsck しないので起動が速いとか、起動中にファイルシステムのチェックができるとか、いいことばかり書かれています。実際、この記事を書く時にたどり着いた情報は「BtrFS にクソハマった話」ばかりなのですが、それほど情報が少ないのはやはり安心して使えるファイルシステムだからでしょう。現実には、論理障害よりも、物理障害もあるわけですから、
「困った!」
時のために、BtrFS の、修復だとかチェック、メンテナンス、スナップショットの設定の方法について、ちゃんと勉強しておくことにします。- 参考にしたドキュメント -
SDB:BTRFS
btrfs scrub start [mount_point]パーティションの論理障害を修復します。
opesuse151:~ # btrfs scrub start /scrub started on /, fsid 8466aee4-2738-4b0a-924a-79edad4b4676 (pid=23058)opesuse151:~ #
brtfs scrub status [mount_point]scrub した結果を確認します。
opesuse151:~ # btrfs scrub status /scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50total bytes scrubbed: 7.54GiB with 0 errorsopesuse151:~ #
-dR オプションを付けると詳細な情報が分かります。
opesuse151:~ # btrfs scrub status -dR /scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676scrub device /dev/vda2 (id 1) historyscrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50data_extents_scrubbed: 247304tree_extents_scrubbed: 31902data_bytes_scrubbed: 7577907200tree_bytes_scrubbed: 522682368read_errors: 0csum_errors: 0verify_errors: 0no_csum: 5030csum_discards: 0super_errors: 0malloc_errors: 0uncorrectable_errors: 0unverified_errors: 0corrected_errors: 0last_physical: 11178868736opesuse151:~ #
btrfs check [/dev/partition]ファイルシステムのパーティションチェックです。※ --force を付けるとマウント中のファイルシステムをチェックできる。
opesuse151:~ # btrfs check --force /dev/vda2Opening filesystem to check...WARNING: filesystem mounted, continuing because of --forceChecking filesystem on /dev/vda2UUID: 8466aee4-2738-4b0a-924a-79edad4b4676[1/7] checking root items[2/7] checking extents[3/7] checking free space cache[4/7] checking fs roots[5/7] checking only csums items (without verifying data)[6/7] checking root refs[7/7] checking quota groups skipped (not enabled on this FS)found 7839363072 bytes used, no error foundtotal csum bytes: 7380260total tree bytes: 261373952total fs tree bytes: 238518272total extent tree bytes: 13942784btree space waste bytes: 41699539file data blocks allocated: 7779311616referenced 7561506816opesuse151:~ #
btrfs filesystem df [mount_point]従来の df コマンドの代わりになるものです。
opesuse151:~ # btrfs filesystem df /Data, single: total=8.01GiB, used=7.06GiBSystem, DUP: total=32.00MiB, used=16.00KiBMetadata, DUP: total=1.12GiB, used=249.25MiBGlobalReserve, single: total=21.73MiB, used=0.00Bopesuse151:~ #
btrfs filesystem usage [mount_point]
opesuse151:~ # btrfs filesystem usage /Overall:Device size: 14.00GiBDevice allocated: 10.32GiBDevice unallocated: 3.68GiBDevice missing: 0.00BUsed: 7.54GiBFree (estimated): 4.63GiB (min: 2.79GiB)Data ratio: 1.00Metadata ratio: 2.00Global reserve: 21.73MiB (used: 0.00B)Data,single: Size:8.01GiB, Used:7.06GiB/dev/vda2 8.01GiBMetadata,DUP: Size:1.12GiB, Used:249.25MiB/dev/vda2 2.25GiBSystem,DUP: Size:32.00MiB, Used:16.00KiB/dev/vda2 64.00MiBUnallocated:/dev/vda2 3.68GiBopesuse151:~ #
sysconfig の File systems の中に、自動メンテナンスの間隔を設定します。"BTRFS_BALANCE_PERIOD" のキーに設定されます。デフォルトは weekly となっています。
SDB:Disable btrfsmaintenance
weekly から none にすると、無効となります。
snapper は初期設定では無効です。snapper コマンドでスナップショットを初期化します。snapper -c create [YourSnapSotName] create-config [PathToYouNeedSpapShot]ここではルートパーティション全体を取っていますが、例えば DB ファイルがあるところとか、 /srv/www/htdocs などを指定します。設定ファイルは /etc/snapper/configs/ の下に作られます。
opesuse151:~ # snapper -c mysnapconfig create-config /opesuse151:~ #opesuse151:~ # ls /etc/snapper/configs -ltotal 4-rw-r----- 1 root root 1169 Feb 27 10:37 mysnapconfigopesuse151:~ #opesuse151:~ # cat /etc/snapper/configs/mysnapconfig# subvolume to snapshotSUBVOLUME="/"# filesystem typeFSTYPE="btrfs"# btrfs qgroup for space aware cleanup algorithmsQGROUP=""# fraction of the filesystems space the snapshots may useSPACE_LIMIT="0.5"# fraction of the filesystems space that should be freeFREE_LIMIT="0.2"# users and groups allowed to work with configALLOW_USERS=""ALLOW_GROUPS=""# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots# directorySYNC_ACL="no"# start comparing pre- and post-snapshot in background after creating# post-snapshotBACKGROUND_COMPARISON="yes"# run daily number cleanupNUMBER_CLEANUP="yes"# limit for number cleanupNUMBER_MIN_AGE="1800"NUMBER_LIMIT="50"NUMBER_LIMIT_IMPORTANT="10"# create hourly snapshotsTIMELINE_CREATE="yes"# cleanup hourly snapshots after some timeTIMELINE_CLEANUP="yes"# limits for timeline cleanupTIMELINE_MIN_AGE="1800"TIMELINE_LIMIT_HOURLY="10"TIMELINE_LIMIT_DAILY="10"TIMELINE_LIMIT_WEEKLY="0"TIMELINE_LIMIT_MONTHLY="10"TIMELINE_LIMIT_YEARLY="10"# cleanup empty pre-post-pairsEMPTY_PRE_POST_CLEANUP="yes"# limits for empty pre-post-pair cleanupEMPTY_PRE_POST_MIN_AGE="1800"
詳細はこちらをご参考下さい。
4 SnapperによるスナップショットとロールバックSLES12 の Snapper のチューニング
snapper を起動したら、YaST2 snapper で、スナップショットの設定をします。opesuse151:~ # yast2 & 定義したパーティションルートに .snapshot ディレクトリが創られます。ここは snapshot の保管場所です。
opesuse151:~ # ls /.snapshots/1/snapshot/.snapshots boot etc lib mnt proc run selinux sys usrbin dev home lib64 opt root sbin srv tmp varopesuse151:~ #
実際のスナップショットの取り方、ロールバックの方法はこちらの過去記事をご参考にしてください。
SLES12が採用した btrfs, snapper を使った Snap Shot
なるほど、SUSE Linux 12, 15 でルートパーティションは標準の BtrFS は COW (Copy On Write) なので、ファイルの論理障害には強いんだ、という事です。しかし物理障害には無力な事には変わりません。やっぱり必要なのはバックアップです。一通りやってみて、Windows の起動直後の chkdisk や EXT3 の場合の fsck の待ち時間を考えると実に楽になったなと実感しています。

2020年 02月 24日
ファイル名とパスの最大長の色々

SUSE に限らず多くの Linux ディストリビューションや UNIX 系では getconf コマンドで NAME_MAX を調べてみると良いでしょう。 255 バイトで、最後の一文字は NULL なので、実質 254 バイトになるはずです。誤っていたらコメントください。これは posix 準拠のためなんでしょうね。
sle15:~ # getconf -a | grep NAMENAME_MAX 255_POSIX_NAME_MAX 255LOGNAME_MAX 256TTY_NAME_MAX 32TZNAME_MAX_POSIX_TZNAME_MAXCHARCLASS_NAME_MAX 2048HOST_NAME_MAX 64LOGIN_NAME_MAX 256sle15:~ #
IBM の資料ですが、getconf の詳細はこちらをご参考ください。
getconf — 構成値を取得する
Samba や NAS などでは 255 「バイト」、Windows では260「文字」。長いファイル名は Samba では使えないわけです。
長いファイル名を扱うことができない
ただし、これは「ファイル名の制限」で、limits.h によるとパスも含める 4096 バイトの様です。これはファイルシステムフォーマットの問題ではなくシステムAPIによる制限です。
最大パスサイズは「バイト」で日本語でパスを作成する場合、UTF8 では3~4バイト使うため、「日本語の文字数」に注意が必要です。
opensuse151:~ # cat /usr/include/linux/limits.h | grep PATH#define PATH_MAX 4096 /* # chars in a path name including nul */opensuse151:~ # getconf -a |grep PATHPATH_MAX 4096_POSIX_PATH_MAX 4096PATH /bin:/usr/binCS_PATH /bin:/usr/binopensuse151:~ #
実際にプログラムを書いて試したヒトがいました。中々面白いプログラムです。
Check File Systems maximum path depth
Now run it:$ time ./createDirectoriesreturn code : -1Created sub-directories : 1018length of pathname : 4096real 0m0.281suser 0m0.004ssys 0m0.180s
私の openSESE Leap 15.1 の環境では若干違いがありました。
opensuse151:~/test # ./ptestreturn code : -1Created sub-directories : 1022length of pathname : 4098
※ 1023 バイト説もありますが、その根拠が分かりませんでした。コメントいただけると幸いです。
ファイルサーバー専用OSの Novell Open Enterprise Server (OES)では、ファイル名そのものは16ビット Unicode で 255 文字、フルパスは 1023 文字です。6.4 Naming NSS Storage Objects
6.4.2 Number of Characters AllowedFor the NSS file system, the maximum length supported for a filename (the name and file extension) is 255 16-bit Unicode characters. The maximum length supported for the full path name (which includes the volume name, directories, filename, extension, and delimiters in the path) is 1023 16-bit Unicode characters.However, different tools, applications, and file systems place different limits on filenames and path lengths, some of which can be more or less restrictive than these limits.
16bit Unicode でパスも含めて 1023 文字です。もっとも、それだけの長さを扱えるソフトウェアやアプリケーションがあるとは限らないのでマウントしたシステムによる、という事です。標準的なシステムより、長いパスを作ってマルチベンダー対応、という事なのですが、良くある話でマルチベンダー固有のトラブルも抱えます。なお、上の記事は、OES2018 のNSSなので OES2 以前のバージョンや NetWare カーネルでは 255 文字という記述もありました。多分ファイル名だけの制限でしょう。
NTFS の概要
拡張パスのサポート: 多くの Windows API 関数には、MAX_PATH 設定で定義された 260 文字のパスの上限を超える約 32,767 文字の拡張パスを許可する Unicode バージョンがあります。
最大 32,767 文字が MAX_PATH 変数によって 260 文字(パスも含む)に制限されています。この数値は Win32 の制限によるもので、グループポリシーで変更できます。> gpedit > コンピュータの構成 > 管理用テンプレート > システム > ファイルシステムに "Win32の長いパスを有効にする" を有効にして > gpupdate を実行します。 例えば、サーバー上の "D:\(フルパス含めて全部で260文字).txt" をネットワーク共有で "\\server\my-long-share\(共有名を含めると260文字超えちゃった).txt" でアクセスする場合などにはこの制限を撤廃すべきでしょうか。やはり「255文字前後が一般的な壁」なので、濫用は要注意です。バックアップからのリカバリなどでも、このファイル名の長さ制限でリストアできないファイルがある場合も考えられます。Windows Server -> Samba でバックアップエラーが起こるとややこしい事になりそうですね。Linux側では、4096(NULL含) のパスの長さなので、 Unix 系OSや macOS とファイル共有すると、ファイル名の長さで Windows からアクセスできないケースも出てくるわけです。
Wikipedia によると
最大ファイル名長255文字(UTF-16での文字数。Appleが改変したUnicode正規化形式Dに正規化される)https://ja.wikipedia.org/wiki/HFS_Plus
残念ながら、パスを含んだ最大の数字は見つからなかった...ので getconf してみました。
etesian-mini:etc uhoge$ uname -a
Darwin etesian-mini.local 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64
etesian-mini:etc uhoge$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.1
BuildVersion: 19B88
etesian-mini:etc uhoge$ getconf NAME_MAX /
255
etesian-mini:etc uhoge$ getconf PATH_MAX /
1024
etesian-mini:etc uhoge$
どうも macOS X 10.15.1 では、ファイル名の長さは 255(NULLを除いて254)バイト、最大パスは 1024 ということになりそうです。古いHFSの場合は31文字です。また、AFP を使う時も 31 文字のよう。
色々調べてわかったのは....
- 大体のシステムでは2020 年現在 255 文字前後のUTF16、またはバイトが、ファイル、ディレクトリ名で使える- バイトの場合と UTF16 の場合がある。- Unix 系システムでは、ディレクトリパスも含めて、4095(+null) で 全部で4096バイトのようだ- Unix 系システムで Samba を使う場合、長いパスは Windows からアクセスできない場合がある。- ただし OS が扱うファイル名の文字コードが UTF16 であるとは限らない。最近は大抵 UTF8 だったりする- Windows10 系は 260 文字だが、「初期の Windows は 254" バイト"」だったりでバージョンによってはバラバラ。- Windows10 系のパスの長さ制限は「拡張パス」という秘密の扉を開けると32,767 文字まで使える- システムが使う文字コードが Shift-JIS だったり、Unicode だったり、UTF-8 だったり EUC だったりするとどうなるか不明- 日本語コードに慣れたプログラマとはトモダチにになっておくべきだ。- バイト数と UTF16、UTF8、の「文字数」とは違う事をエンドユーザに説明するのはインド人にウナギを食わせるくらい難しい- 特に文字数とバイト数の違いに注意。chars が、いわゆる char 変数なのか、文字通りの「非アルファベット」の複数バイトの文字数(letter数)なのか- 職場を辞めたヤツが、Mac からファイルサーバーの日本語フォルダの深さをチャレンジ、しかも読み込み専用のフラグを立てて退職したことを思い出した。頭にきた。- 長くて深いディレクトリ名、ファイル名をユーザは使わないで欲しい。ってか、よくそんな面倒なことするなよ。- ファイルシステムに制限がなくても(no limit) OS の API 制限に引っかかることが多い。Windows のエクスプローラは「アプリケーション」である。- アプリケーションからアクセスできないファイルは夜作られる。- ファイル名とパスの長さは、誰か Wikipedia に記事を書いてまとめて欲しいくらい、面倒である。
他にも文字コードの違いや機種依存文字、使えない記号符号特殊文字などもあります。これはまた別の機会に調べてみます。
コンピュータ名(ホスト)の命名規則? 15文字の63バイト制限、ホスト名の命名権利はだれの責任?
2020年 02月 19日
SUSE Linux で fuser, ファイルロックしているプロセスを強制停止
マウント中のデバイスを umount しようとすると ”Device busy” なんてことがあります。あるいは、ファイルを開こうとしたら、ファイルがゾンビなプロセスなんかに、ロックされている。そんな時に覚えておきたいコマンドが lsof と fuser です。lsof はインストールされていないようなので、YaST か zypper を使ってインストールします。
SUSE Linux でパッケージインストールの色々な方法

まずは使い方から
opensuse151:~ # fuserNo process specification givenUsage: fuser [-fIMuvw] [-a|-s] [-4|-6] [-c|-m|-n SPACE][-k [-i] [-SIGNAL]] NAME...fuser -lfuser -VShow which processes use the named files, sockets, or filesystems.-a,--all display unused files too-i,--interactive ask before killing (ignored without -k)-I,--inode use always inodes to compare files-k,--kill kill processes accessing the named file-l,--list-signals list available signal names-m,--mount show all processes using the named filesystems orblock device-M,--ismountpoint fulfill request only if NAME is a mount point-n,--namespace SPACE search in this name space (file, udp, or tcp)-s,--silent silent operation-SIGNAL send this signal instead of SIGKILL-u,--user display user IDs-v,--verbose verbose output-w,--writeonly kill only processes with write access-V,--version display version information-4,--ipv4 search IPv4 sockets only-6,--ipv6 search IPv6 sockets only- reset optionsudp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]
opensuse151:~ #opensuse151:~ # lsof /home/lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfsOutput information may be incomplete.COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEsftp-serv 21170 knakaj cwd DIR 0,47 404 258 /home/knakajbash 21204 knakaj cwd DIR 0,47 404 258 /home/knakajoosplash 23270 knakaj cwd DIR 0,47 404 258 /home/knakajsoffice.b 23289 knakaj cwd DIR 0,47 404 258 /home/knakajsoffice.b 23289 knakaj 3u REG 0,47 8107 826 /home/knakaj/test/test.odtsoffice.b 23289 knakaj 24uW REG 0,47 91 728 /home/knakaj/.config/libreoffice/4/user/uno_packages/cache/log.txtsoffice.b 23289 knakaj 26uW REG 0,47 127 772 /home/knakaj/.config/libreoffice/4/user/extensions/bundled/extensions.pmapdbus-daem 23304 knakaj cwd DIR 0,47 404 258 /home/knakajat-spi-bu 23305 knakaj cwd DIR 0,47 404 258 /home/knakajat-spi-bu 23305 knakaj mem REG 0,47 787 825 /home/knakaj/.config/dconf/userdbus-daem 23310 knakaj cwd DIR 0,47 404 258 /home/knakajat-spi2-r 23312 knakaj cwd DIR 0,47 404 258 /home/knakajgvfsd 23318 knakaj cwd DIR 0,47 404 258 /home/knakajgvfsd-fus 23323 knakaj cwd DIR 0,47 404 258 /home/knakaj
-a 全部、-u ユーザID、-v 詳細モード
opensuse151:~ # fuser -avu /home/knakaj/test/test.odtUSER PID ACCESS COMMAND/home/knakaj/test/test.odt:knakaj 23289 F.... (knakaj)soffice.bin
-k で kill、 -i で kill の確認メッセージ
opensuse151:~ # fuser -avuki /home/knakaj/test/test.odtUSER PID ACCESS COMMAND/home/knakaj/test/test.odt:knakaj 23289 F.... (knakaj)soffice.binKill process 23289 ? (y/N) yopensuse151:~ #
-m でマウントオプション
opensuse151:~ # fuser -mauv /mnt/sdcUSER PID ACCESS COMMAND/mnt/sdc: root kernel mount (root)/mnt/sdcknakaj 22618 f.c.. (knakaj)smbdopensuse151:~ #
-m と ki オプションでモンダイの smb プロセスを kill する。
opensuse151:~ # fuser -mauvki /mnt/sdcUSER PID ACCESS COMMAND/mnt/sdc: root kernel mount (root)/mnt/sdcknakaj 21867 f.c.. (knakaj)smbdKill process 21867 ? (y/N) y
セッションが kill され、開いているファイルがリセットされました。ディレクトリに cd している場合は bash がディレクトリファイルをオープンしています。よくある話。
opensuse151:/home/knakaj # fuser -vau .USER PID ACCESS COMMAND/home/knakaj: root 22884 ..c.. (root)bashroot 22982 ..c.. (root)fuseropensuse151:/home/knakaj #opensuse151:/home/knakaj # fuser -vau /home/knakaj/USER PID ACCESS COMMAND/home/knakaj: root 22884 ..c.. (root)bashroot 23149 ..c.. (root)fuseropensuse151:/home/knakaj # cd ..opensuse151:/home # fuser -vau /home/knakaj/USER PID ACCESS COMMAND/home/knakaj:opensuse151:/home #※ ちなみに bash のプロセスを kill するとそのターミナルは固まります......