2021年 03月 01日
zabbix 5.2 openSUSE Leap 15.2 SNMP でデバイス監視
zabbix5 で SNMP デバイスを監視する方法を説明します。 SNMP 管理機能がある手頃な機器がないので、ここでは openSUSE Leap 15.2 に snmpd を走らせて、監視対象としています。
Zabbix4 はこちらZabbix4.2 snmp監視 デバイスのグラフを表示させるまで
ー openSUSE Leap 15.2 の snmpd
openSUSE Leap 15.2 ではデフォルトで net-snmp はインストールされています。
SUSE Linux Enterprise(SLE) ではインストールされていないので、YaST か zypper でインストールし、YaST > System > Service Manager より snmpd を Start/Enable にセットします。
ー community String と、送信相手の設定
/etc/snmp/snmpd.conf を編集し、次の行を変更して、送信先コミュニティストリングと、応答先のアドレス範囲を指定します。さらに詳細な設定ができますが、ここでは最小限の説明です。
# rocommunity public 127.0.0.1
rocommunity public 192.168.1.0/24
変更したら systemctl か YaST の Service Manager からリスタートします。
myhost:~ # systemctl restart snmpd
ー snmp の応答確認
zabbix サーバーから snmpwalk を使って、応答があるかどうか確認します。指定する OID は System の値 ”.1.3.6.1.2.1.1” あたりが適当でしょう。
# snmpwalk -v 2c -c CommunityString target_host.Yourdomain .1.3.6.1.2.1.1
zabbix5:~ # snmpwalk -v 2c -c public myhost.i.islandcenter.jp .1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Linux myhost 5.3.18-lp152.63-default #1 SMP Mon Feb 1 17:31:55 UTC 2021 (98caa86) x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4839) 0:00:48.39
SNMPv2-MIB::sysContact.0 = STRING: Sysadmin (root@localhost)
SNMPv2-MIB::sysName.0 = STRING: myhost
SNMPv2-MIB::sysLocation.0 = STRING: Server Room
: 略
ー 監視ホストを zabbix に作成
詳細はマニュアルをご参考下さい。ここでは最低限の説明をしています。あまり役に立たないこのページよりも正しい事が書かれています。
1 CONFIGURING A HOST
snmp でネットワーク内のデバイスオブジェクトを作成し、snmpwalk で応答があった Linux デバイスの snmp 監視ターゲットを作成します。
左のメニューから Configuration > Hosts > 右上の "Create Host"
Hostname : myhost
Group : Select > "Type of host" ここでは Linux Server
Interface > "Add"
Interface > "snmp"
IP か DNS 名をセット（DNS名を使う時は”Connect to” を DNS に）ポートは 151 そのまま。
SNMP version は、デフォルトで v2、コミュニティストリングは、public なら、そのまま、必要に応じて変更
最後に "Add"
ここで"public"以外の、コミュニティストリングをネットワーク全体で使っている場合、 Macros > Inherited and host macros > より 、下の方にある ”{$SNMP_COMMUNITY}” を Change して、別なコミュニティストリングに変更します。
テンプレートを指定します。
Hosts > MyHost > Template > Select > 一番近いテンプレートを選択：ここでは ”Linux SNMP” を選択します。
”Update” で登録更新します。
※複数のテンプレートが選べますが、AND 条件でダブるとエラーになります。例えば Linux SNMP と Generic SNMP は同居できません。
※テンプレートは Zabbix Share https://share.zabbix.com/ に豊富にありますが、一発では動かない事が多いです。
Zabbix をアップデートした場合は、旧バージョンのテンプレートが引き継がれるため、テンプレートの選択はかなりややこしくなります。
登録して Configuration > Hosts のリストの中に、登録したホストが出てきて、数分以内に右の Availability が「緑 SNMP」 になれば、とりあえずオーケーですが、グラフの描画が始まりません。
グラフを見るには
Monitoring > Latest data より、Host Group > Select , Host > Select, Application > 監視するアイテム、ここでは CPU を選んでいます。試しに CPU Utilization にチェックを付けて”Display Graph” を押します。
CPU使用率のグラフが確認できました。
ー 監視アプリケーションの有効化
とりあえず CPU 負荷はすぐグラフ化できましたが、他の情報を見るには Application を Enable にする必要があるようです。
Configuration > Hosts > "Myhost" を選び "Applications" のリンクを押して、全ての "Applications" を Check して Enable ボタンを押します。
同様の操作を "Items" についても行います。
開始してから、最低 3600 秒、一時間待ちます。しばらく放置した後
Monitoring > Latest data > Host > Application : interface
でトラフィック送受信のグラフが描画されました。
ー まとめ
Zabbix で SNMP 監視ルータやスイッチの死活・トラフィック監視がは、見えない物を見える化する事です。
とりあえず、Linux Host を対象に zabbix から最低限のリソース管理ができました。SNMP 監視は設定方法に当たり外れが多いようです。まずは最低限、見たいことが見れればラッキーかもしれません。グラフの描画が始まらないのは焦りますが、とにかく一時間以上待って変化がないかチェックします。
まずはデフォルトでは3600 秒 、一時間ごとに SNMP でデバイスの値をディスカバリーるようなので、焦ってはいけないという事です。
テンプレートをとっかえひっかえしている内にグラフが描画される場合もあります。Applicatin を Enable すると動く場合もありました。何をどうすれば、SNMP での監視タスクを作れるかの最適解はまだ見つけていません。
Zabbix の難点ですが、マイナーなバージョン変更でもUIが変わったり、テンプレートが追加されてしまい、過去の経験とは違う手順を踏まなければならない事があります。バージョンアップする場合は、書籍の情報や、素人っぽい私のブログの様を参考せず、そのバージョンのオフィシャルドキュメントを見ておく事です。バージョンによって大きく手順が違う場合があります。
あわせて読みたいZabbix 5.2 on openSUSE Leap 15.2 インストールzabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定
▲
by islandcenter
| 2021-03-01 16:01
| Linux
|
Comments(0)
2021年 02月 25日
Zabbix 5.2 on openSUSE Leap 15.2 Install
Zabbix 5.2 on openSUSE Leap 15.2 Install
openSUSE Leap 15 の良い所は、有償版 SUSE Linux Enterprise 15 (SLE15) と、バイナリレベルの互換性があり、openSUSE Leap 15 から SLE へのアップデートが保証されている、という点です。SLE から openSUSE へ乗り換えても、ほとんど操作に違和感がなく、スムーズに移行できます。
openSUSE Leap は RHEL --> CentOS の様な、ソースレベルの互換性、クローンではありません。有償版 SLE のサブスクリプション購入の前に、openSUSE Leap で、とりあえず検証、トレーニングを行ってから、SLEに移行するというパスが用意されています。
ー zabbix
zabbix はヨーロッパ・ラトビア生まれのオープンソースライセンスのネットワーク管理ツールです。エージェントを使ったサーバーの負荷やリソース管理、SNMP を使ったルータやスイッチのトラフィック監視、Ping などサービスの死活監視など、広い用途でネットワークを監視できます。この種のソフトウェアとしては急速に利用者が増えており、キラーアプリケーション化して育ったプロダクトです。
何よりUIがブラウザという事で、操作に必要なプラットフォームを選びません。サーバーは主要なディストリビューションを網羅しています。
という事で、openSUSE Leap 15.2 に SLE 15 用の zabbix 5.2をインストールする手順を検証してみました。
zabbix5.2 をインストールする前の、openSUSE Leap 15,2 のインストール、Web LAMP のインストールは、次の記事、動画を参考にしてください。
ー Install openSUSE Leap 15.2
openSUSE Leap 15.2 のインストールは次の記事、動画を参考にしてください。
openSUSE Leap 15.2 Install First Look.(インストール)
※ /var は異なる仮想ディスク、別パーティションにしています。/var/lib/mysql/zabbixdb に zabbix データベースが作られます。/ パーティションは BtrFS 16Gb 以上、/var は別な仮想ディスクとして XFS フォーマット、10Gb 程度あれば、規模にもよりますがとりあえず充分でしょう。
ー Install Web LAMP on openSUSE Leap 15.2
openSUSE Leap がインストールできたら、Web LAMP 環境を導入します。大体の手順は次の動画を参考にしてください。
openSUSE Leap 15.2 Web LAMP install with YaST（動画、音出ます）
それでは zabbix5 をインストールします。
ー mariadb の有効化
まずは、mariadb をスタートさせ、起動を有効化します。
YaST > System > Service Manager から mariadb を Start/Enable します。もしくは systemctl で起動します。
ー Download and install Zabbix
https://www.zabbix.com を開いて右上の DOWNLOAD リンクを開きます。
バージョン > Distribution(SLES) ＞ Version(15) > DBタイプ(MySQL) > Web Server(Apache) の順でクリックするか、ここでは次の URL を開きます。
このページに、必要なコマンドラインのサジェスチョンが記載されているので、順に実行します。
ー リポジトリの登録
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'
YaST で確認します。
次の操作は openSUSE Leap では不要です。
# SUSEConnect -p sle-module-web-scripting/15/x86_64
― パッケージのインストール
zypper か YaST を使って次のパッケージをインストールします。
zabbix-server-mysqlzabbix-web-mysqlzabbix-apache-confzabbix-agentzabbix-web-japanese (<- 日本語化する場合必要)
ー MySQL の開始/設定
事前に決定しておく事。ここでは次のユーザ名、パスワード、データベース名を使います。適時おき替えてください。
mysql の root パスワード : mysqlpwdZabbix Database 名： zabbixdbZabbix Database ユーザ/パスワード： zabbix/zdbpwd
ー mysql の DB 作成
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
５分待ちます。
ー zabbix_server.conf の書き換え
zabbix_server.conf の次の三か所を必要に応じて書き換えます。
gedit /etc/zabbix/zabbix_server.conf &DBUser=zabbixDBName=zabbixdbDBPassword=zdbpwd
ー restart zabbix_server
YaST か systectl コマンドで zabbix_server/agent, apache2 を onboot start/enable にします。
systemctrl restart zabbix_server zabbix_agent apache2systemctrl enable zabbix_server zabbix_agent
yast > System > Service Manager
ー フロントエンドの起動、セットアップ
firefox http://localhost/zabbix &
言語の選択 > とりあえず英語のまま次へ
データベースへ接続
Database name: zabbixdbuser: zabbixpassword: zbxpwd
Server Detail : 特に変更なくNext
Default Time Zone : UTC+9 Asia/Tokyo
Summary
WebUI ログイン
Login:Admin/zabbix (デフォルト初期値です case sensitive 大文字小文字注意)
フロントエンドのセットアップが終わると、ダッシュボードが起動します。ダッシュボードの時計がローカルタイムになっている事を確認してください。
Monitering > Hosts > Zabbix Server が（ZBX 緑）になっていれば、サーバー/エージェント共に稼働中です。
グラフも出てきました。
ー ポイント（忘れがちなこと）
・データベース名、DBユーザ名、パスワードは事前に決めておく事です。ダウンロードページの指示通りでも構いませんが、デフォルト password じゃいかにもですからね。大抵、何らかのエラーが起こるとすれば、この三つの設定がおかしい。・Web LAMP のインストール手順が、サジェスチョンに含まれていないので、事前にインストールして mariadb を起動しておく事。・WebUI へのログインは Admin/zabbix です。ケースセンシティブ、大文字小文字注意です。クラウド運用する時は早めに変更しておく事。・ UI のURLは、http://ip-address/zabbix です。/index.html を書き換えて、リダイレクトすると良いでしょう。
ー まとめ
openSUSE Leap 15.2 で zabbix5.2 をインストールしてみました。公式サポートは SUSE Linux Enterprise 15 ですが、インストール自体は幾つかの間違えやすい点に注意すれば、特にストレスなく行えます。
CentOS8 の将来性に不安があるのなら、無償でオープンフリーの openSUSE Leap は、SLE の信頼性を引き継いでおり、rpm に慣れていて Debian/Ubuntu 系はちょっと、というシステム管理者にとっては一つの代替手段になります。
大規模なデータセンターでもなく、数十台のサーバー、スイッチなどのデバイスを管理したい中小規模のネットワークなら openSUSE Leap + zabbix の組み合わせは一つの良い選択になります。既に仮想環境が用意できているのなら、Zabbix5 は是非試して欲しいネットワーク管理ツールです。
zabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定zabbix4.2 を zabbix5.0 アップデート
▲
by islandcenter
| 2021-02-25 13:48
| SUSE
|
Comments(0)
2020年 12月 02日
openSUSE 15: zabbix5.0 から 5.2 へのアップデート
Zabbix 5.2 がリリースされたので openSUSE 15.1 にインストールされた zabbix 5.0 からアップデートしてみました。
- Snapshot の削除と復元ポイントの作成 -
まず、大きな変更をする前に、システムのバックアップとスナップショットの確認をします。
もし KVM/XEN など、仮想化されたされたシステムをつかっているなら、仮想イメージのバックアップを取っておく事です。何が何でもバックアップは重要です。
次に、パーティションの空きを確保し、十分な空き容量があるかどうかを確認します。
yast2 > miscellaneous > Filesystem Snapshot (yast2 snapper) を起動して、スナップショットのうち、古いスナップショットを削除(Delete)します。スナップショットは定期的にメンテナンスされますが、パーティションの空きを最大確保するには、大きな変更点がある古いスナップショットを削除するのが最適とされます。
次に アップデート前の SnapShot を作成( Create ) します。
こちらの記事もご参考下さい。zypper up してシステム空き領域がなくなってしまってハマってしまう反省文です。
BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保
ちなみにデータベースは
/var/lib/mysql/zabbix
に作成される様です。ここは XFS フォーマットなのでスナップショットは取っていません。
本家 SUSE Enterprise Server のドキュメントもご参考下さい。
7 Snapperを使用したシステムの回復とスナップショット管理 REPORT DOCUMENTATION BUG#
- アップデート -
次のダウンロードページには SUSE Linux Enterprise 15 (SLES15) でのインストール手順です。今回はインストールではなくアップデートなので、
- リポジトリを変更して- YaST でアップデート- YaST で Zabbix を再起動
という手順です。
zabbix5.2 ダウンロード
ダウンロードページにある次のコマンドを実行します。
# rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm
# zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'
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:~ #
次に YaST > Software Management > Software Repositories から、リポジトリが変更されている事を確認し "Enabeled" , "Autorefresh" の二つをチェックします。
次に YaST > Software Management から "zabbix" を Search して、Zabbix 5.2 のパッケージでチェック済み項目を全て、右ボタンで "Update" に変更します。
自動的にアップデートが始まります。
- サービスの再起動 -
YaST > System > Service Manager から、 Zabbix_Server/Agent の Start/Stop を切り替えて、サービスの再起動をして、状態が On boot/Active になっている事を確認します。
コマンドで再起動するには systemctrl コマンドを使います。
opensuse151:~ # systemctl restart zabbix-server.serviceopensuse151:~ # systemctl restart zabbix-agent.service
サービスを再起動したら # tail /var/log/message して、エラーが出ていない事を確認しておきます。
アップデートが終わったら、 ブラウザで http://myzabbix_ip/zabbix にログインして、ダッシュボードの下中央にある Zabbix のバージョン番号を確認します。
どうやらうまく行ったみたいです。
▲
by islandcenter
| 2020-12-02 11:16
| SUSE
|
Comments(0)
2020年 11月 18日
PDCAサイクルから考えるセキュリティポリシーの見直し
ーセキュリティポリシーは、ホワイトカラーの業務改善の一つの要素であるー
PDCA サイクルと呼ばれる「継続的改善」手法は、本来QC活動：「品質保証」用語として用いられます。
PDCAサイクル
-1. Plan : 計画-2. Do : 実施-3. Check : 見直し-4. Action : 執行
という４つの要素がグルングルンとサイクリックに回って「品質改善」を目指そうという皆さんご存知の QC 活動ですね。
で、セキュリティポリシーというのは、ビジネス上重要な、ホワイトカラーにとっては一つの重要な「業務改善」の手段なのです。
ーなんの Plan もなくDo されて始まるセキュリティポリシーー
スタートアップビジネスでは、「とりあえずやっちまおう」的なノリで仕事を始めてしまうので、セキュリティポリシー自体の Pサイクル(Plan) も何もないところから始まって(Do) してしまいます。
つまり、セキュリティポリシー自体、何もないところから始まり、いつの間にか「慣習化」された理由で Do されているところがおおいのではないかとそう考える訳です。
これは、スタートアップ企業だけではなく、大手企業でのスタートアップビジネスにもあり得る話かもしれません。悪しき記憶として印された、ADSLビジネスを始めた頃のソフトバンクの大量の情報漏洩事故なんかがそうでしょう。なんの情報管理ポリシーもなかったわけですね。
ー文書化されたポリシーと慣習化されたセキュリティポリシーー
セキュリティポリシーに限らず、コンピュータシステムを使う上で重要なのは、運用ルールが文書化されているかどうかの視点です。コンピュータの命名規則や、ユーザアカウントの命名規則も、文書化されていれば破綻することは少ないでしょう。この様なルールも PDCA のサイクルで見直しが必要なのですが、不思議と文書化されている組織は少ないようです。多くの運用ルールは「慣習化」されたモノから始まるのです。
コンピュータ名（ホスト）の命名規則？ 15文字の63バイト制限、ホスト名の命名権利はだれの責任？
ユーザアカウント名は８文字以内にすべきか？ユーザの命名規則の理由と対策
ー一番重要な Check サイクルー
セキュリティポリシーは「慣習化されたポリシー」と「文書化されたポリシー」の二つに分類されます。
そこで、セキュリティポリシーが「どういった理由でその様に慣習化されたのか」「文書化されたポリシーは徹底されているか、形骸化しているか、妥当かどうか」という「現状チェック」、つまり PDCA サイクルの Check のサイクルを把握し理解することがとても大切なのです。
この中で「慣習化されたポリシー」が「有効」と判断されたら、セキュリティポリシーの中に文書化すべきであるし、文書化されたポリシーでも、不適切で運用上、意味のないものであれば削除したり、方式を見直すべきなんですね。
特に文書化されていない「慣習化したポリシー」には、どういった背景があるかを吟味することは大切です。意外とエンドユーザの考えることは「妥当」であり「有用」な事が多いのです。
「取引先の要求でこんな感じで文書ファイルを扱わなければならない」
とか
「パスワードは難しく、かつ簡単にこんな風に個人的に管理している」
とか、色々あるわけですね。
特に「パスワードはメモ帳やノートに書かない」というのは、今の時代「死語」に等しいという事も、ユーザ部門はよくわかっているのです。
ー厳格なポリシーは形骸化し易いー
パスワードは大文字小文字記号混じりで１２字以上、同じアルファベットはつかってはダチかんぞ、３０日に一度パスワード変えないとダメだ、なんていうセキュリティポリシー、よく見ますよね。
しかしユーザはよく知っているのです。システム管理部門が知らないだけで、実業務に関してはユーザさんたちはその道の玉筋金太郎並みに抜け道を作るンです。自分のパスワードのルール化です。
意外と社内システムで使われるパスワードなんて、厳しくしなくても簡単には他人がわかるものじゃありません。それよりパスワードを管理して運用させるための利用者側、運用担当者双方のコストを考えれば、厳格なポリシーが如何に形骸化しやすいかを理解できそうなものです。
セキュリティの厳格化を誤ると、運用面でも形骸化が進み、本来守らなければならないルールも形骸化します。その結果「社内ルールがルーズになりセキュリティインシデントが発生する」「本来遵守すべき事項が守られず捏造されたセキュリティチェックだけが残された」という結果にも繋がりかねません。
こんなのは形骸化したルールを見直せば如何に現実性がなかったポリシーだったかがわかるでしょう。
霞ヶ関でパスワード付きzipファイルを廃止へ 平井デジタル相
ー同意を得てのアクションー
ここまで書いてみて、言いたいことは、セキュリティポリシーの PDCA サイクルは「利用者の日常業務の PDCA に関わるもの」だと言うことです。セキュリティポリシーの Check サイクルは、利用者の業務全般の、無理、無駄のチェックのプロセスを含み、業務の運用改善にも繋がるものなのです。
PDCA サイクルの中で重要なのは、Check のサイクルなのです。重要なものをチェックしてピックアップし、形骸化して意味をなさないポリシーは削除する。取捨選択して、現状をどう改善するか。Plan と Do はシステム運用者の業務の範疇でしょう。そして重要なのは Action に必要な、セキュリティポリシーの文書化と徹底するための組織を挙げての規定化です。
必要なことであれば、就業規則にも取り入れ、罰則規定も絡めて検討します。
ーセキュリティルールの習慣化ー
どの企業、組織にも「文化」というものがあります。セキュリティポリシーの習慣化、セキュリティ文化は、組織の意識を向上させます。
PDCA の Action がもたらした結果です。
よく「ウチは ISOxxxxx の認証を取っているから」という事をウリにする組織がありますが、あれは形骸化して「形だけのセールストーク」に使われる仕組みなんですね。
逆に安心して使える取引先は、たとえ ISMS認証がなくとも、数分お話しただけでしっかりしているな、という印象があるものです。ちょっとしたことでもスキがなく素人さんと話しても理路整然としています。
こういった組織はセキュリティだけではなく実業務についても信頼できてスキがないんです。
タグ：
▲
by islandcenter
| 2020-11-18 16:02
| 雑文
|
Comments(0)
2020年 07月 26日
BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保
BtrFS の甘い罠、アップデートの前に空き容量を確保
どんなショボいシステムでも、安易に変更は加えない方がいいわけです。openSUSE Leap 15.1 のシステムを# zypper dupしたところ、見事に罠にハマりました。BtrFS の罠です。スナップショットを取っているので、空き容量がなかったんです。空き容量がないところでパッケージのアップデートなんかすると、openSUSE Leap 15x はルートパーティションが Copy On Write の BtrFS ですからファイルは上書きではなく、差分をドンドンと CoW してしまう。遂にディスクの空きを使い果たして、中途半端な zypper dup の結果、「システムが立ち上がらない」という最悪の結果に陥りました。BtrFS のスナップショットの残骸ってロック掛かっていて、レスキューディスクで起動しても消せないのですね。という事で、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> が一番使われやすいコマンドだという事です。
- ncdu, du コマンド -
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."
Google 先生の翻訳によると
"したがって、一般に、btrfsファイルシステムの空き容量を正確に見積もることは不可能です。はい、これは最悪です。ユーザーがどれだけのスペースを残したかを簡単に理解できるようにする方法について本当に良いアイデアがある場合は、私たちに知らせてください。また、btrfs開発の最高の心がこの問題について考えていることに注意してください。少なくとも数年間は、簡単な解決策はまだ見つかりませんでした。"
とあり、もう BtrFS では、正確な空き容量確認は現時点で「不可能」と断じています。
そもそも、ファイルコピーの段階で、当然システムの API は空き容量を確認するわけですが、その元ネタは何なんだろうか？ という疑問がわいてきます。
- 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 によるメタデータの修復、デフラグ、破損ファイルの修復を実行します。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 など、あるいはメジャーアップデートする時、同じファイルであっても物理的なファイルそのものが上書きされずに、古いファイルはスナップショットに「移動」し、空き領域に新しいファイルが作られることです。
- まとめ -
BtrFs においては、ファイルの空き領域に常に注意し、ファイルコピーなどによる空きスぺースの Run Out には気をつけよ、という事です。
▲
by islandcenter
| 2020-07-26 13:28
| SUSE
|
Comments(0)
2020年 05月 31日
zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック
openSUSE 15.1 に入れた zabbix5 で、インターネットの疎通、サービス状態の確認をする方法です。
この春先から、どうもインターネット接続が遅かったり、切れたりする症状に悩まされています。その都度、google なんかに ping して、レスポンスを確認してたのですが、メンドクサイ。何しろ「リモートワーク」の時代。地方拠点から本社への出張なども憚れると、どうしても気になるのはインターネットトラフィックです。
その後の新型コロナウイルスのフレッツトラフィックへの影響
という事で openSUSE Leap 15.1 で動いている zabbix5 に、外部サービスの死活監視、ping の応答時間などをチェックさせてみました。
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 監視
などを、可視化できないものか試してみました。
- Zabbix5 で HTTP サービスと PINGの監視 -
左のメニューから、Configuration > Hosts > リストが出てきたら、 Create Host
Host Name と group はとりあえず Google で Linux Servers、Interfacesは Zabbix Agent を remove して とりあえず IMPI、ホストのDNSを設定して Port は443 をセットして "Add" ボタンを押します。この辺りは適当でかまわないかも.....
次に左上の"Template" メニューを開きます。
Link new templates から "select" ボタンで”Linux Server” > Template App http や https サービスをチェックします。
ping もチェックしたいのなら Template ICMP Ping もチェックします。
最後に "Add" ボタンを押します。
Hosts の上にある Applications, Items, Triggers を、それぞれ Enable ボタンを押して監視を開始しました。
幾つかの HTTP サービスが Down State で見えない時があるのが分かります。
サービスがアップしているかどうかは。１と０の値で評価されるので、グラフがV字化している時は繋がりにくかったことが分かります。
ダウンしていた事が報告されていますね。
Yahoo.co.jp と Google.com の状態です。ダウンしている時間帯がほぼリンクしているので、海外との通信より、ウチと契約先の ISP、あるいは契約回線の問題だと判ります。
GoogleDNS と、契約先の ntp.bbtec.net (経路的には一番近いかな)を ping して値をみてみます。まず Ping 応答が無くなり、結果 HTTP サービスも動かないという事です。
拡大しました。全体的に google のサービスより Yahoo BB の ping 応答が遅い様な感じですね。Avarage も、Google DNS より ntp.bbtec.net の方がレスポンスが悪い様です。海外との回線よりＩＳＰ内部の遅延がある様です。
朝の3時は iOS のアップデートが始まります。このタイミングでも google のレスポンスは見事に遅延しています。
ダメじゃん、ウチの契約回線が悪いのだ..... と判断しています。
SoftBank Air の様な容量無制限モバイル Wifi でも、共有 IP (シェアドIP)なので、グローバルIPが切り替わる都度に、遅延や切断は起こりそうです。まぁ、モバイル Wifi では明示的に速度制限の対象となる場合もあるので「ビデオ会議」などのライブストリーミングが制限されない事を確認すべきでしょう。
Softbank Air: Wifi ネットワークの暗い闇、シェアード IP
--
今回は外部の ICMP Ping とHTTP サービスを Zabbix5 でトレンドを見てみました。今までの Zabbix4 までのグラフ機能では、複数のデバイスのトレンドが見れなかったので、良くなったと思います。
例えばオンラインミーティングが始まる午前９時とか、午後１３時とかにハッキリ遅延が起こるのであれば、これは、コロナ騒動でのリモートワークの影響だとキッパリ言えそうなんですが、冒頭の IIJ のブログにもあるように、リモートワークの影響ではなさそう。やっぱりウチの Yahoo BB のプアな回線状況が原因と考えられます。
さて、プアな自宅回線の強化、月々の利用料金はどう会社負担になるのでしょう、今後のリモートワークの課題ですね。
応用として、例えば支店に設置したインターネットVPNルータや管理用 HTTP などのサービスの状態のチェック。自社の提供するサービスの死活管理などに利用できます。Pingの応答速度は、折れ線グラフ化できるので、昼間と夜間の違いはないかを可視化できます。
拠点間ルータの snmp 管理機能や、リモート拠点間のサービス状況を調べる事で、拠点の「ネットが遅い」問題の原因を検討する事もやってみる事です。明かに、ISPのサービスレベルの問題であると判断できる要因が長期のトレンドで見つかるなら、契約ISPを変える為の稟議書を書く根拠にもなります。
Zabbix のように応用力の高いツールがあれば、「その時」ではなく、たとえ数時間でもトレンドが見える事はよいことです。
▲
by islandcenter
| 2020-05-31 13:27
| SUSE
|
Comments(0)
2020年 04月 08日
誰が買う？ Windows10 タブレットは失敗作
Windows10 タブレットは、もう終わった技術なのです
- インターネット端末の Microsoft のシェアは３０％を切っている？ -
いうまでもなく Windows はPC分野の８０数％のシェアがあり。１０数％が Apple 残りが Linux という事は、いろいろなリサーチにある訳ですよ。じゃぁ、インターネットのサービスを受ける、あらゆるデバイスの何パーセントが Windows なのか。スマートフォン、タブレットを含めれば、恐らく５０％もないんじゃないでしょうか。多分スマートフォンが過半数なので、実際の「インターネットにおける Windows のシェア」はPCだけで３割もあればいいほうでしょうね。
PR
- 高価すぎて重すぎ -
Windows10 で最低限欲しいと思うスペックを考えると Core i3m とか i3yと言った Core 3 系のモバイル向けCPU が欲しくなるところです。ディスコンになった Atom 系SoCでは人を馬鹿にしている。正統派 Celeron でやっと使える感じがします。Windows Update を問題なくこなせて、安定して使うには、最低６４Gbのストレージが欲しい。しかし、「Window が動くタブレット」として考えるなら、２５６Gbのストレージが欲しくなってしまうでしょう。そう考えると、自動的に12～３万円程度は最低限予算が必要なんですよね。しかし意外と Core i3 系のCPUは人気がない。というかメーカーもこのクラスより、より高価な Core i5/7 系を売りたがる。こうなると安くても１５万円コースですね。キーボードもマウスもない Windows に１５万円も普通払いません。しかし、「Windows デバイスを快適に使う」なら、オプションのキーボードとマウス、あるいはデジタイザペンは必須です。それなら普通のクラムシェルか 2 in 1 ラップトップを私なら選びます。２Gbのメインメモリ、３２Gbのストレージ、Atom系 SoC では、「一応 Windows が動くタブレット」でしかなく、実際に使い物になるとは思えません。それでもWindowsがとりあえず動く環境にするには５万円前後するわけで、この値段で Android や iPad などの他社製タブレットならすコスコつかえるわけですよ。
- 処理が重すぎ -
大体、 Windows はフットプリントが重すぎて、タブレットには向かないぞ、という事だ。GIGAスクール構想の実現について1人1台のPCで教育のICT化を推進――日本マイクロソフトが「GIGAスクールパッケージ」を提供開始Google、管理などの無駄な時間を減らし4万5千円以下で提供可能な「Google GIGA School Package」を開始この勝負、どうみても Google に分があるんだが、どんなものでしょう。GIGA スクールパッケージに Windows は勝ち目がない。３万円の Android や Chrome タブレットを子供の Youtube 端末として使わせている親が、わざわざその倍の値段もして、華奢で壊れやすく安っぽい筐体の７万円の Windows タブレットを買うわけにはいかない。私が、中高で「情報C（情報社会）」を教える立場だったら、間違えなく Windows10 タブレットは「アウトオブ眼中」です。Chrome Book で安く済ませて、余った予算を別に使う事を考えるでしょう。
 マイクロソフト Surface Pro 6 [サーフェス プロ 6 ノートパソコン] Office Home and Business 2019 Windows 10 Home |  iPad mini Wi-Fi 64GB (最新モデル) |  HUAWEI MediaPad M5 lite 8 タブレット 8.0インチ Wi-Fiモデル |
- 最悪の Windows Update -
スリープ解除して、通信が開始されるといきなり始まる Windows アップデート、いざ使おうとすると半日は使えないモバイルデバイス。それが Windows10 タブレットの宿命。毎月のアップデートだけで、格安SIM二月分のパケット料金と貴重な時間を使いたくない。そんなものに普通１５マン近い大金払いませんって。よっぽど Apple の iPad がひどくてもこんなにひどくはない。それにもっとシンプルで堅牢なハードウェアだし、軽くて高性能、高機能なのです。４万円も出せば普通に使えるし、１２８Gb程度のストレージがあれば、スチルカメラやビデオカメラ並みに使える。それに iOS や Android, Chrome タブレットは機能を絞っただけシンプルで長時間のモバイル運用ができる。
- Windows だから求められるデスクトップアプリという呪縛 -
街を歩いていて、ちょっと調べ事をしたいと思えば、スマートフォンより小型のタブレットは実にいい選択なのです。だけどそれが Windows タブレットとなれば、たとえタブレットと言えども、そこに "Windows らしさ" を求めるユーザ需要があるのですね。たとえタブレットであろうとも Microsoft Office が使えないと嫌だという、ユーザの奇妙なわがままを満たす必要があります。 Office アプリが必要であれば、当然マウスとキーボードもいるよね。「いざという時 MS Office が使える」という事は、その「いざと言う時」のために普段使わないキーボードもカバンに入れておく必要があるわけです。そして充電用のアダプタとケーブル。もう、 Windows10 なんて、一般家庭では「年賀状の印刷に年に一度使う」ためにある、というのが実態じゃないでしょうか。
- 銀行取引、金融機関では蚊帳の外 Windows 10は信頼されていない -
最近の銀行取引では、大体 iOS か Android のタブレットで最適化されたアプリケーションが頒布されていまして、もし Windows タブレットで、銀行振り込みしようと思ったら、別に iOS か Android が必要と言う矛盾、無駄。そもそも、銀行振り込み用のアプリがない、どころかワンタイムパスワードアプリもない。携帯電話必須という不自然さ。ちなみに、 Windows ストアから片っ端に、大手都市銀行の名前を入れて調べると良い。一体、どこの預金者が、Windows OS を信頼しているんだろうってくらいに、ストアアプリは、銀行から嫌われています。頼むから Windows 端末から、預貯金の操作してくれるな、という位の総スカン状態なのですね。Windows PCのブラウザ経由で決算してくれるなって位の嫌われようなのです。専用の exe アプリケーションすら配布されない。 Windows は金融機関から唾棄され嫌われているのです。
- モバイルOSから撤退した Microsoft -
ご存知の通り、 Windows Mobile はディスコンになり、既にサポートも終わっているわけで、 Microsoft としては、「マイクロソフト部屋に最後に残った幕内力士：Windows10」 をモバイルデバイスの切り札に残しているわけです。徳俵にかろうじて親指が残った崖っぷち張り出し大関、小錦みたいな状態。とてもじゃないけど、こんな危なっかしいOSを、フットプリントの小さな x86 環境にインストールして使う事自体、燃えないゴミにお金を投資するようなもの。Windows10 タブレットは、もはや大相撲の中日に全廃している張り出し大関のようなものです。とてもじゃないけど、私は「Windows10 タブレット」には、「引退という引導」を渡すべきだとおもいます。
- Intel はブランドを整理すべきだ -
これほど、顧客が混乱しているのは Intel のブランド戦略が破綻しているからなのですね。もっとブランドを整理すべきです。「Celeron に名前を変えた Atom」 があったり、ほとんど使われない Pentium があったり、低スペック、低電圧版の Core i3/i3m/i3y なんてモデルがあるのはいかがかと思います。その未整理な Intel のブランディング戦略にただ乗りしている、タブレットベンダーも責任を取るべきでしょう。「２コア４スレッド搭載タブレット」とか言っても、中途半端な Atom 系 Celeron だったりするわけで、ほとんど消費者騙しです。２コア４スレッド搭載「パーソナルコンピュータ」であれば、最低でも Core i3 程度を想像するのですが、よーく仕様を見ると Celeron でしかも Atom 系コアだったりします。※ Nxxxxx Celeron というＮで始まる Celeron は、バチモノ系だそうです。つまり、もう生産中止になって在庫がごっちょりある Atom 系 CPU の悪く言えば生産余剰した、リマーク品なのですね。 これを消費者に 「Atom とは別物」と言う、リ・ブランドして売りさばくのが Intel の今のやり方なのです。Celerorn 選ぶくらいなら AMD の Ryzen 系、モバイル SoC 選んだ方がよっぽどウソがない気がします。
- 使えない Windows タブレットの使い道 -
それでも Windows10 タブレットのニーズは根強くあるでしょう。それは「組み込み用途」です。こないだガス屋の端末見たら、Windows タブレットでした。 Windows 7 だったけど。しかし、企業でこういった外勤者に何百台と使わせるとなると、コスト、持ち運びの容易さ、堅牢性、電池の持ち、アプリケーション開発の容易さなどを考慮すると、別に、保険のオバちゃんが Windows タブレットを使わなければならない必然性はありません。ブラウザ経由のアプリケーションであれば、別に何でもいいんです。
- まとめ -
ということで、Windows10 タブレットの将来性のなさ、致命的な欠点、わざわざ選ぶ理由がない事などをズラズラとまとめてみました。それでも Windows10 タブレット買いますか？ それとも Android や Chrome, あるいはPC化する iOS 搭載 iPad ? もうタブレット戦争では、ほとんど Windows １０タブは「アウトオブ眼中」、タブレットOSシェアのパイチャートでは「その他」に分類されるようになるでしょう。
202x 年 Windows 最期の日
▲
by islandcenter
| 2020-04-08 14:58
| Windows
|
Comments(0)
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 の修復 -
btrfs scrub start [mount_point]パーティションの論理障害を修復します。
opesuse151:~ # btrfs scrub start /scrub started on /, fsid 8466aee4-2738-4b0a-924a-79edad4b4676 (pid=23058)opesuse151:~ #
- 前回 scrub した結果の確認 -
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 のファイルシステムのチェック -
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 での df (利用量)の確認 -
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 にすると、無効となります。
- snappper の初期設定 -
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 のスナップショットの設定 -
snapper を起動したら、YaST2 snapper で、スナップショットの設定をします。opesuse151:~ # yast2 &
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 の待ち時間を考えると実に楽になったなと実感しています。
▲
by islandcenter
| 2020-02-27 14:20
| SUSE
|
Comments(0)
2020年 02月 24日
ファイル名とパスの最大長の色々
ファイル名とファイルパスの最大長について。
Samba にファイルを保存しようとしたら、「ファイル名が長すぎる」と怒られたので、ファイルサーバーで保存するファイル名の長さ、トータルのパスの長さを調べてみました。
ここでは Samba だけではなく、Windowsや macOS のファイル名、パスの長さ制限についても調べました。
- SUSE Linux（openSUSE Leap 15.1）-
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 では２６０「文字」。長いファイル名は Samba では使えないわけです。
長いファイル名を扱うことができない
ただし、これは「ファイル名の制限」で、limits.h によるとパスも含める 4096 バイトの様です。これはファイルシステムフォーマットの問題ではなくシステムAPIによる制限です。
最大パスサイズは「バイト」で日本語でパスを作成する場合、UTF8 では３～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 バイト説もありますが、その根拠が分かりませんでした。コメントいただけると幸いです。
- Novell NSS はパスも含めて 1023の Unicode 文字 -
ファイルサーバー専用ＯＳの 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 文字という記述もありました。多分ファイル名だけの制限でしょう。
- Windows NTFS -
NTFS の概要
拡張パスのサポート: 多くの Windows API 関数には、MAX_PATH 設定で定義された 260 文字のパスの上限を超える約 32,767 文字の拡張パスを許可する Unicode バージョンがあります。
最大 32,767 文字が MAX_PATH 変数によって 260 文字（パスも含む）に制限されています。この数値は Win32 の制限によるもので、グループポリシーで変更できます。> gpedit > コンピュータの構成 > 管理用テンプレート > システム > ファイルシステムに "Win32の長いパスを有効にする" を有効にして > gpupdate を実行します。
- MacOS HFS+ -
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$
 |
- まとめ -
色々調べてわかったのは....
- 大体のシステムでは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バイト制限、ホスト名の命名権利はだれの責任？
▲
by islandcenter
| 2020-02-24 14:12
| SUSE
|
Comments(0)
2020年 02月 19日
SUSE Linux で fuser, ファイルロックしているプロセスを強制停止
SUSE Linux での fuser、ファイルを開いているプロセスを kill します。
マウント中のデバイスを umount しようとすると ”Device busy” なんてことがあります。あるいは、ファイルを開こうとしたら、ファイルがゾンビなプロセスなんかに、ロックされている。そんな時に覚えておきたいコマンドが lsof と fuser です。lsof はインストールされていないようなので、YaST か zypper を使ってインストールします。
SUSE Linux でパッケージインストールの色々な方法
- fuser のヘルプ -
まずは使い方から
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]]]
- lsof でディレクトリ以下のオープンファイルを確認 -
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
- fuser でオープンファイル、プロセスID、ユーザを確認 -
-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
- fuser でオープンしているプロセスを kill -
-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 するとそのターミナルは固まります......
▲
by islandcenter
| 2020-02-19 12:45
| SUSE
|
Comments(0)
